When referring to data model, we are discussing the architectural structure of the way data is stored in an application.

Salesforce.com and the Force.com platform come with a standard data model and allow you to customize that data model for the purposes of custom functionality.

Ironically, the standard data model is accessed and configured in your org under the "customize" menu of your org setup. For instance, if you were to add a custom picklist value to the account type field, you are configuring the standard data model. You can also add to the standard data model by adding custom fields on a standard object like Account.

Custom data model is in the "Create" menu. This is where you would add a custom object (let's say Invoice) to your org. Here you are creating a new place to put data that didn't exist before.

The reason we use the term "data model" in the first place is to make a distinction between where we put data (the data model), how we view data (user interface), and how data is acted upon (business logic).

Salesforce org configuration blurs these lines a bit, because whenever you add to the data model by creating a new object, we also automatically give you a user interface (page layout) and business logic (the ability to save, delete, etc.).

These three components, data model, user interface, and business logic are also components in the underlying architecture that salesforce uses which is referred to as Model-View-Controller (MVC).

Model: Data Model
View: User Interface
Controller: Business Logic

Hopefully that gives you some context behind the term data model.