You aren't using impersonation. If you were, then this would be working (assuming your database were otherwise correctly configured to allow access from the impersonated user).
EF is not using a "built-in" account. It's using whatever account the worker process is running under, which in most cases will be either an Application Pool identity, or Network Service, both of which use the machines Active Directory account for credentials.
In other words, EF uses whatever the connection string tells it to use, and if you're telling it to use a trusted connection, then it uses whatever the process/thread is running under.
In point of fact, impersonation is not supported in IIS7 or greater when running in Integrated pipeline mode. The reason for this is that IIS7 is more strongly tied to .NET and supports asynchronous handlers. Asynch handlers have issues with impersonation because the thread that started the handler, may not be the same thread that resumes the handler when the async request resumes after giving up its thread to do the async work.
In general, unless you have a very specific use case, you probably should not design your architecture to require impersonation, as this has a lot of repercussions.
If you need to utilize a resource with a specific user, then you can use a WindowsIdentity principal and Impersonate that way, but this has to be done in the confines of a small block (the network call itself).
I'm not sure how you are trying to do impersonation, but it's obviously not working. In most cases, you should be getting an error if you try to impersonate on IIS7+, so the question really is... What makes you think you're using impersonation?
