You could use the TurnKey Hub for easy deployment of a pre-configured Django appliance to Amazon EC2. If you prefer the command line you can use the Hub's API or CLI, for example:
$ hub-launch django [-options]
If you've enabled TKLBAM (encrypted backups of changes to files, databases, package management state, even users and groups), you can launch a new cloud server which will be automatically restored upon boot:
$ hub-launch $BACKUP_ID
Take that a step further and say you're developing your Django app in a local VM. When you're ready to deploy to the cloud you just trigger a backup, then launch it in the cloud.
The state of the art here is to use AWS CloudFormation to bring up the instance.
With CloudFormation you can specify the base AMI and other resources, such as an Elastic IP, and AWS will either bring up the stack or rollback the entire transaction if something goes wrong.
Then, you specify the script to set up the AMI as a userdata script, and that will be run as root when the instance boots.
The downside here is that the CloudFormation syntax is very funky, and 100% AWS specific. This might justify sticking with your strategy of simple fabric scripts.
People may also want to check out Ian Bicking's Silver Lining tool: http://cloudsilverlining.org/
[+] It would clearly apply to physical servers as well, but probably this carefree approach would be used most on VPSes.
I have personally found that even distro-specific scripts require some tweaking across various hosting providers due to the default configuration of VPSs being different in each case. It has generally not been worth the effort for me to write complete bootstrap scripts so generic that they will work on anybody's VPS, but it's usually trivially easy to adapt whatever I have written to the quirks of a new hosting environment if the need arises.
reading the config file turns out to be a good place to start.
I plan to add common "re-deployment" stuff, but is very hard to decide what to include because everybody uses django differently. We need to develop best practices and conventions.
Then the script would work with multiple providers, not just Amazon.
Capistrano is Ruby, so is Rails.