There's absolutely nothing wrong using the EF-generated classes. That's what they're there for.
But if you misapply the technology, you are in for a lot of problems. For example, a lot of beginners will try to use those EF-generated classes for everything. They'll take the classes, marshal them across an AppDomain boundary with WCF or Remoting, and maybe they'll bind to them on their front ends. That might work for a quick and dirty CRUD-based application, but it's not going to fly for anything with any real size.
Why not? Because EF-generated classes are modeled in the data "domain" of your application, not the presentation "domain". What a user might want to interact with is often not an object which is 1:1 with a table in your database. For example, a user might have a grid of "Products". Inside this grid would be the total dollars sold of the product, along with certain indicative data about the product. While the indicative data (Name, Size, etc) will probably come right off the Product table and therefore the generated Product class from EF, the aggregate data (total dollars sold) is an aggregate value.
What we typically do is use the EF-generated classes in our service, and then use the service to translate the EF classes into ViewModels which we then bind to on our front ends using WPF (or whatever your favorite technology is). That gives us the separation of concerns we're looking for.