My first answer would be to save yourself the trouble and find a good data mapper ORM and focus on your business objects and logic, and let the ORM worry about persistence. The "data mapper" part is important here, because it alows you to have a domain layer which is completely separated from the persistence. So you'll have just simple classes without any persistence leaking in in the form of a base class, or interface or anything.
Now if you still want to try and build your own, this is how I'd do it:
This is heavily based on how the Doctrine2 ORM for PHP works:
The entry point for whatever code is using the ORM is your EntityManager, this is what you use to fetch and save your entities/domain objects. Then you have your data mapping layer, which should be able to be injected with mapping info (in xml or whatever), so it can figure out how to connect tables to classes and columns to properties, and how to deal with relationships.
Underneath all that, you have the actuall db access layer, which has to be flexible enough to deal with different databases. So when you ask for an entity from the EM, it will go through the mapper layer to find out what table to use, then to the dbal to fetch the data, and again through the mapper to map the data to an object. When you save an entity, the EM will use the mapping layer to find out the table/columns from the object/properties, and send the data to the dbal to actually save it.
Doctrine also uses auto-generated proxy classes for your objects. These proxies are injected with the EM to allow for loading of relationships.
This is a largely simplified version of things, and I'm sure someone has already done it in whatever language you're using. Doctrine for instance also has an ODM, for MongoDB (this is still beta).
You'll notice that I never mentioned anything like a base class or an interface that you'd use in your domain objects. They should be absolutely stupid when it comes to persistence, and the only "leakage" from the persistence to the domain layers happens in the proxy classes, which should look exactly like your domain objects to the application that's using them. This way your domain code stays clean and simple.