DB Ghost
Overview
The DB Ghost products satisfy the requirements.
The Change Manager product can generate scripts (DROP and CREATE scripts, which can be run 'manually') for all of the schema objects as well as static data. The Change Manager Professional product can be automated to do so via command line, e.g. for scripting a particular development database regularly.
The Packager, Packager Plus, and Packager Plus Professional products can deploy changes in the form of a specific version of the scripts created by Change Manager. Packager Plus can perform a 'dynamic upgrade', basically a schema and static-data 'sync' between a target database and a source database, where the source database can be created from scripts. Packager Plus can also create an executable that can be distributed to perform the dynamic upgrade in the relevant target environment. Packager Plus Professional can be automated to do all the aforementioned via command line.
'Syncing' versus Migrating
One common strategy for maintaining changes to a database schema involves explicitly maintaining database migrations, both for upgrading and for downgrading. A migration is effectively code for performing a single change to a database instance of a schema.
You can maintain migrations with DB Ghost, but it only just allows you do to so, it definitely doesn't support it beyond that. However, I think this is A Good Thing.
Instead of migrating databases during a deployment, DB Ghost instead 'syncs' the target database (the database to which you wish to deploy changes) with a model source database that is generated during deployment from a specific version of the database schema. Instead of executing specific migrations, it compares the source and target databases, and makes the changes necessary to the target database to resolve any differences it detects.
The chief advantage of syncing versus migrating is that instead of maintaining all of the scripts for all of the migrations one can (mostly) maintain scripts for the current version of all the database objects in the schema. Thus the code that represents the schema is organized by database object instead of spread out over a (potentially large) number of migrations.