Since you're staying with 2008R2 (both source and destination) there is nothing stopping you from just backing up and restoring all of your databases including the system databases. As Shanky pointed out, this would save a great deal of time:
1) Backup and Restore Databases - Is this the best option?
It's an option. If you need the downtime to be less, you can use mirroring or log shipping (or do it by hand) to keep the databases in sync and then migrate during a fast downtime or cutover.
Please note that system databases cannot be log shipped or mirrored and would need to either be frozen or copied right before the cutover.
2) Migrate Logins - use Microsoft KB? kb/918992
If you restore the master database to the new instance, no migration should be needed. All server level logins are stored in the master database.
3) Migrate Credentials/Certificates - what is required for this?
If this is inside of SQL Server, these would be held in their respective databases (and possibly master as well). The one difference would be the service master key (SMK) that would change. You make want to back that up and restore it on the new server if you're relying on automatic key decryption.
4) Migrate SQL Server Agent Jobs - (Object Explorer Details > Select All Jobs > Script Job; Is this process the best option?)
If you restore the msdb system database, all agent jobs will be held in it. There would be no need to script->restore.
5) Migrate SSIS Packages - (How to do this?)
If the SSIS packages are on the filesystem (not default) it would be trivial to create the same location on the new server and copy. By default the SSIS packages are held in the msdb system database and restoring it would get you to the same place, just like #4 and previous.
6) Migrate Database Mail Accounts/Profiles - (Create a script or recreate in SSMS?)
This is also stored in msdb. See #4, #5.
7) Recreate assemblies
These live in their respective databases. If backup and restore is used, this should not be a problem. Any assemblies outside of SQL Server would need copied to the new server.
8) Recreate Linked Servers
These also live in the master database, see #2.
I am not a SQL Server DBA, I use MySQL for my jobs. But some truths are universal. :-)
1) Should I expect any gains in performance or reliability breaking up the main data file in the manner I described?
I have observed that the benefit of any scalability optimization depends on the queries you run.
It's practically the definition of optimization that any method of optimization will improve one type of query workload as it worsens some other types of workloads.
2) How do I make these changes on a production database server where I can schedule (at most) a 30 minute downtime window per day?
I would set up a replica server (I gather in SQL Server land these are called Subscribers). Restructure the physical tablespaces of the replica. Then it doesn't matter how long it takes, as long as it can catch up to the master after the restructure is done.
I'm assuming SQL Server replication is asynchronous and also agnostic about physical layout, as MySQL replication is. But I don't know that SQL Server supports this.
Once you're done restructuring the replica, and it catches up to be in sync with its master, you can "cut over" probably by changing DNS entries for the respective server instances. Then the downtime is minimal, and brief, regardless of the size of the databases. The downtime should include a few moments to make sure all changes from the master have "drained" and been applied fully to the replica.
The tradeoff being that you need an extra set of DB server(s), at least temporarily. This is a case where using virtual servers or cloud servers can really save you!
Best Answer
Moving the data is pretty easy. If you are using full text search that feature isn't available in SQL Azure yet. Neither is FILESTREAM. If you require full text search then Azure isn't for you.