I'm wondering how much stuff from my Whatever::Object::save method needs to be pushed into the subclass.

Thats the beauty of subclasses, you don't need to answer that question now. You should be sure to design your base class with small methods which each represent a single unit of work. This way the subclasser only needs to override as little as nessecary. Also, throw out the idea that your subclass writers will be able to write their subclasses without reading and understanding the base class. Its overly idealic to think that is possible (at least in most cases).

I guess its a question of how much I care...

Well, thats a good question. You should care as much as you have time to. Since you are writing this for your own (and your companies) purposes, then you should focus on that aspect of it first and formost. You will drive yourself nuts trying to write something that works for everything. Just get a solid MySQL subclass working, and leave the issues of other DBD's aside for now. If when you go to add PostgreSQL support, and you need to munge with the internals of Whatever::Object, you can do that. If your classes are designed well, then it won't ever matter to the end user what you do to the objects internals.

What databases don't support auto-increment fields? Alas, my experience is limited solely to MySQL.

Well, my experience is mostly with MySQL too. I have done some limited work with PostgreSQL, which doesn't directly support AUTO_INCREMENT as a keyword, but can be emulated by using the SEQUENCE type instead. I have also messed around with MS Access and MS SQL Server, but that was a while ago and I had no clue what I was doing anyway. In general I think there will almost always be some way of creating an AUTO_INCREMENT-like column for the primary key. Again, I would say don't worry about DBD specific stuff outside of MySQL until you actually need to use it. If MySQL works good, then you have covered a sizable percentage of the population anyway, and that is a good start.