Hey Everett,
Packages (and subpackages) are a way to logically and physically separate groups of class and map files. Classes in the "modx" package essentially "are" the MODx core model, and they exist physically in a certain place. If you’re designing a custom model which is not logically a part of the MODx core, say, an extension or 3PC, or a domain model for a particular project, then you can keep that model isolated by having it in it’s own package. Quip and Engage are two current example components where the model is given a custom package.
The baseClass is going to be xPDOObject or something that extends it. The most commonly used example of an extended class is xPDOSimpleObject - which just pre-defines a primary key named ’id’ for you. If you are modeling a table with a PK named ’id’, and extend xPDOSimpleObject, you don’t need to define the ’id’ field your xPDO model schema. You might also extend xPDOObject to give it some other behavior, like I’ve done here
http://github.com/netProphET/xPDO-Collection-Tools
I can’t comment on the MySQL tables business, I don’t keep up on that stuff like I should ;-)