Drupal travels pretty well -- here's how to do it.

1. If populated, truncate the local instance's 'cache' table. Naturally, I didn't do this before exporting. In addition to causing issues on the target server, I could have saved some bandwidth by doing this earlier than I acutally did.
2. Create a new database on your target server.
3. Export your local instance's Drupal database.
4. Import the dump into your newly created target server's database instance. I gzipped the database export using a newer version of phpMyAdmin than my hosting provider does, and had issues. This was resolved by rexporing using no compression.
5. Modify $DRUPAL_HOME/sites/default/settings.php to reflect your target server's settings
6. FTP your local instance's files to your target server.

In optimal conditions, this works. However, on my target environment, I have a couple of unresolved issues beyond my control:

1. Clean URLs don't work. As I do not have access to httpd.conf, I can't make the changes outlined in my previous post. This necessitated changing all of the inter-page links to the ugly '?q=' hrefs. There wasn't that many links to change, so I did it by hand -- if there were considerably more, I probably would have sed-ed them. Also, I needed to change the 'Clean URLs' entry in the variables table to reflect my unclean environment.
2. Anything that relies upon imap functionality, such as the mailhandler.module, doesn't work because my hosting provider did not compile it into PHP. WordPress sidesteps this neatly by using a third-party POP3 library. I'm working on a Drupal implementation thereof.

Other than that, it was remarkably painless.