For your infrastructure we would recommend you set up Deployment Manager as follows:
You will need to add each of your SQL Servers in the environments tab.
You should have only one project with a single database step.
To set up so that the database has a different name on each server there are two possibilities:
1) As you suggested, name the server with the database name and the on the database package step settings you can set the database name to be $(RedGateDatabaseServer) to reference the server name
2) You can override the database name by setting up a project variable. You will need to go the the project variables page and for each machine add a variable with the same name e.g. DeployDatabaseName and then in the drop-downs select the database server, and then enter the ppropriate value. Then on the package step page change the database name field to reference that variable (For our example change it to $(DeployDatabaseName).)
With regard to migration scripts, we are currently working on support for SQL Source control's migration scripts natively in Deployment Manager, and we expect that to only require a single package for both schema and migrations. If you have custom migration scripts you wish to run, you will need to write a powershell script to run your .sql scripts and then you can either package them in with your existing database package, or create a different package and add a second step to your project. An example of how to do this can be found here
I don't quite understand what you mean by 'the state of the packages'. The way Deployment Manager is intended to work is that each package represents the state of a component, and deploying that package means "Make it look like this." For databases, we use SQL Compare technology to update the database schema.
Hope this is helpful, let us know if you have any more questions