Presently, the top level package name is just SQL, so I have sub-packages such as SQL::Object, SQL::Link, SQL::Statement, SQL::Object::ResultSet, SQL::Link::ResultSet, etc.

This will be a problem as SQL::Statement is already taken, and possibly some of the others too. A quick search on http://search.cpan.org will tell you. A possible solution to this is to put your entire framework under a single top level namespace, this can usually be accomplished with a careful search and replace. Personally I prefer the top-level namespace method, as it tends to make it much easier to use a framework within other projects since I don't need to worry about namespace conflicts.

What is the best mechanism via which to receive feedback on naming issues?

The module mailing list (actually there are a two, one for module authors, and the other for announcements), you can find them http://lists.perl.org/. And of course, there is always here too, a node prefixed with "RFC" is all it takes, and I am sure you will get plenty of feedback.

With regards to testing, I'm fairly confident in my ability to write good tests as far as verifying correctness is concerned, but I also want to adhere to the various conventions for CPAN modules.

As long as it plays well with Test::Harness, you should be ok. I would assume Test::Unit does that. You can also talk to the people on the perl-qa list, you can find out more about that at http://qa.perl.org/. Personally I have never used Test::Unit, so thats about all I can offer on that subject.

On a related thread, I'm curious as to how I should go about testing interactions with a database on a user's system.

Try using mock objects, in particular you can use DBD::Mock.

With regards to writing documentation, ....

POD is the standard, your categories sound about right, there is no "must-have" set out there, its really up to you. Although I would recommend the BUGS and SEE ALSO sections, as well as a AUTHOR and COPYRIGHT AND LICENSE. I personally also like to have a CODE COVERAGE section to include my Devel::Cover report in.

I'm also wondering about error handling, specifically how to trap and report errors to the user

I prefer exceptions (with plain old die), but TIMTOWTDI. However, in larger frameworks I have written I have sometimes created exception objects with stack tracing abilities and such, but personally I have not decided myself on the best way to do that (Carp, Exception::Class, etc) so I am actually interesting in what the other monks would say about that.

I'm sure there are many other important considerations when publishing a CPAN module, so please feel free to chime in about the things that I may have forgotten.

Well, I would actually say that you have thought of/covered a lot of them. But to avoid putting my foot in my mouth, I will let the others comment on that :)