IMO, you need to start decoupling your code by moving towards a more layered approach. I am not quite sure what you need to achieve by testing WCF in isolation. I suggest having three layers and their tests as below -
Data access - uses EF and its DB context and implements a data access interface. You should unit test this without mocking EF's db context. Tests for this layer would be "state" dependent. By that I mean, your tests will work with real data and database for the CRUD operations. You just need to make sure you do not persist the changes to the db after the test run. One can use Spring.Net's testing library to achieve this or simply run your tests under a transaction scope and roll back the transaction after every test run (in the clean up).
Business logic - contains the business logic and works with the data access interface. Use any DI framework like spring.net or ms unity to inject the data access layer. You should unit test this by trying to avoid actual database calls. This is where something like a NMock, Rhinomock or MOQ comes into picture. Set up boundary and exception conditions using mocks and make sure your business logic addresses all the concerns.
WCF service layer - works with you operation and data contract. Ideally only forwards calls to business logic and translates response to data contract. I prefer having two types of tests at this level: a) unit tests for testing the translation and proper call forwarding. b) few basic integration tests using a proxy and some test data that go through the entire stack without any mocking.
The only problem I have with MS fakes is that it ships with VS2012 ultimate version and hence has a much lesser user base than something like a MOQ.