Yukky database... well, given that exists then the first thing you need to do is only allow access to the DB via sprocs, effectively encapsulate the DB in its own API. Once you do this, it'll eventually be possible to replace/redesign it without any client knowing.
Sounds like you've already done this, so good so far.
Now, accessing that API can be done in any number of ways, and using EF to do this is a good RAD way of doing it, even if SQLClient will be faster - doesn't make too much difference all in all.
Mapping a sproc's results to a ComplexType is exactly what a ComplexType is designed for (don't try to use it as if it were an EF view of a DB). Its a temporary result type that does not map to the underlying table - its effectively a dynamically generated type that contains just the results from the sproc and has no relation to the actual DB structure.
However, the problem comes when you try to write these back to the DB - you have to tell EF that the data in the type maps onto a DB table (or it won't know what to do with it), and we are trying to remove the whole DB schema from the service code, accessing the DB through its sprocs only. If you have sprocs to write, then there's no reason you can't just unpick the individual elements of the type and pass them to the relevant sproc in the WCF service. In this case, you simply make it easier to code your service to client code as EF does the class creation for you. Of course, if you've already got such classes for the sproc then its not really going to help you much.
So I think its safe to say he's right, its a simple and worthwhile convenience mechanism that should work well for you - assuming you're not trying to subvert the sprocs, or have a similar mechanism in place. You might find issues with getting the definition of the types into all parts of your chain, depending on how it all gets compiled together, but that's a solveable problem. I would get him to knock up a PoC demonstrating how a new service would call a simple sproc and transfer the data to the client (no need to write the web code to go with it) and back again, and review that. I think you'll find that it does what you've already been doing in a way that means the compiler does a load of boring work for you.
As for reducing the need to go Entity->DTO->View... there's a lot of complexity in web MVC that was put there because Ruby on Rails did it that way, and everyone says MVC is a great way to split your code up. My personal view is that MVC inside the same layer is just over-engineering the problem (that might be good if you only have that layer talking to the DB, not if you already have a well designed 3-tier solution). If you already have a web service and DB layer accessed via sprocs then you've done it right already, no real need to replicate this architecture in the web server as well! So yes, I'd remove as much of the web view code to make it as simple as possible.
