It comes from the field of systems engineering where they use the Entity Relationship Diagram tool to design systems.
What they do is start by laying out the entities (things like customers, purchase orders, purchase order line items, etc.). Each entity is a conceptual thing. Then you generally create an entity class for each entity, and a database table as your backing store. What the entity framework allows you to do is take a database schema, assuming it's already a good representation of your entity diagram, and automatically generate entity classes to encapsulate those.
Since an entity is an abstraction of the real things in your system, by creating a class for each entity, it's a nice way to architect your system to put the relevant code for each entity in the right place. The way the framework works is that it creates two files: an auto generated file that maps to the fields of the database, and a "custom" file where you can put custom logic. These are defined as partial class files, so they're joined together at compile time to form one class, but it keeps your data access and business logic nice and separate. You can then re-generate the auto-generated partial side of the class any time your database schema (entity relationship diagram) changes.
Other nifty features:
- The framework understands the relationships between entities, so once you have a "purchase order" entity, you can automatically grab all the purchase order line items (it's just a property of the entity that returns a collection)
- You can implement entity inheritance (for instance, an employee could inherit from contact)
- Linq to Entities!