Although I tend to agree with Tim about the "religious" element of framework choices, I still find it a bit odd that so many people are willing to comment on the EF when they so clearly haven't bothered to learn how it works. The EF, it turns out, would be a lousy version of NHibernate, just as hammers make poor screwdrivers. It is important to understand the EF on its own terms.
Before I address some of the points raised in comments here, I'll add that we have just shipped version 2 of a production web app with 0 lines of SQL and 100% of all DB access done through either the EF or the ASP.NET membership API to our clients. I speak here with real-world experience with using the EF, something which, regretfully, is clearly not true of the authors of most of the comments on the EF I've seen thus far.
In general, I think it's a mistake to extend your entity types. That the author of the blog post Tim cited (1) wasn't aware it was possible and (2) thinks this is the route to implement DDD tells me all I need to know about his real-world EF experience: He hasn't got any.
POCO support became a very big deal to users of certain ORMs because they didn't have a functional LINQ implementation for many years. Since you were essentially stuck with whatever type objects came out of the black box, having control over the parent type became a very big deal. So big, in fact, that writing your "POCOs" with every member declared public virtual began to be seen as no big deal. On which planet is this a "plain" type? It's a proxy base, not a POCO. The so-called "POCOs" aren't POCOs at all. It's just that they prefer to compromise on encapsulation and performance rather than on parent type. It's probably a legitimate compromise within the limitations of their toolset, but nothing to get cocky about.
But the EF works differently; it's every bit as easy to materialize an arbitrary type via LINQ projections as the type you actually mapped. If you're building something to send objects over the wire instead of to be used internally, and must have clients which can't depend on the EF, then you use RIA services or write an ADO.NET Data Service. All the hard work will be done for you. The EF is the basis for a family of tools handling the problem of projecting data in a DB onto various types of clients, not a single, standalone tool which attempts to handle every single data transformation an app might need internally, in one fat framework. Let the EF handle projection from RDBMSs into object space. You can then use, for example, LINQ to Entities to project into persistence-ignorant types, or RIA services to project onto a Silverlight-friendly wire format. Asking one tool to handle every projection any app might ever need is begging to be stuck in a ghetto with that tool.
The EF is based around the notion of "value objects." These are types with properties but no behaviors. It turns out that value objects work very well for certain specific problems, like sending data over a wire or sitting in the "no man's land" between the RDBMS and OO programming. It's important to understand the separation of concerns here: The point of the entity types is to get the RDB data into the object space. You can then write business types which implement your app, and project the entity types onto the business types. You then have the freedom to implement your business types with zero compromises for persistence. And you can change your RDB schema when need be. You need only change your entity mapping and BO projections, rather than the BOs themselves.