Sim. O ponto é usar o banco de dados real apenas para testes de integração que não precisam ser executados com tanta frequência e todo o conjunto de testes de integração geralmente é executado apenas no servidor de compilação.
Isso ocorre devido a inicialização lenta do EF durante o teste de unidade (você pode tentar mudar para x86). O tempo também é consumido pela geração de visualizações. As visualizações podem ser pré-geradas o que geralmente é feito para reduzir a inicialização e a inicialização do sistema real, mas no caso de acelerar os testes de unidade usando a visualização de pré-geração não ajudará muito porque você apenas moverá o tempo de teste para compilação.
Andar por aí significaria apenas usar o script SQL antigo e simples. O tempo adicional necessário para esta operação pode ser gasto na geração desse SQL. Eu acho que o SQL não está em cache porque a execução normal do aplicativo normalmente não precisa mais de uma vez, mas você pode pedir ao EF para fornecer pelo menos a parte mais importante desse SQL, armazená-lo em algum lugar e executá-lo sempre que precisar . O EF é capaz de fornecer SQL para tabelas e restrições:
var dbSql = ((IObjectContextAdapter) context).ObjectContext.CreateDatabaseScript();
Você só precisa ter seu próprio SQL pequeno para criar banco de dados e usá-los juntos. Mesmo algo como o seguinte script deve ser suficiente:
CREATE DATABASE YourDatabaseName
USE YourDatabaseName
Você também deve desativar a geração de banco de dados no código primeiro para fazer isso funcionar e assumir o controle do processo:
Database.SetInitializer<YourContextType>(null);
Ao executar o SQL de criação do banco de dados, você precisará de uma string de conexão separada apontando para
Master base de dados. 
