Which Orm Frameworks Will Build and Execute the SQL Ddl for You

Use hbm2ddl to generate SQL DDL for database schema update (without losing data)

It might not be the best way to do this in production environment, but if you are not "live with thousands of users", here's how to do it:

set hibernate.hbm2dll to update (this is a hibernate property, set it in hibernate.cfg.xml, or in the spring config, if you use it)
every time you (re)start your application, the database schema will be updated with the new fields and constraints.
old fields may not be removed, so you can go and clean them up manually
primitives, corresponding to columns with not null should be assigned a default or you should go and make a manual UPDATE query. Otherwise you'll get runtime exceptions.

Making changes to domain-model using code-first (ORM) while in production

First a disclaimer, I don't have much experience with EF and I would assume it is similar in this regard to nHibernate. I answered similar question here. The bottom line is that EF and NHibernate are just an ORM frameworks. They have intimate knowledge of your domain but only in its current state, they don't know history. ORM can generate database schema, but this feature is only usefully for initial rollouts and integration testing. You can not rely on it in a production application that evolves and need upgrades (to both schema and data).

In my experience there is no magic tool that will write upgrade scripts, they have to be written manually or at least reviewed by developer. Tools can provide you a framework for executing these scripts, like RoundhouseE. Scott Allen has an excellent series about 'forward-only, run-once' approach.

Entity Framework or SQL Server Management Studio?

Assuming you are working on a brownfield project. Then for a given user story:

1) Design and unit test your domain model.

2) Then integration-test your infrastructure. This includes testing repository implementations against database that gets created dynamically for these tests (can be in-memory or embedded). NHibernate generates schema for you automatically, not sure about EF.
Being persistence-agnostic definitely helps here because you can test against SQLite but run against SQL Server for example.

3) Then manually write migration scripts for your production database. There is no black magic that will help you with this step. The script can later be executed by a framework like RoundhousE. More information here.

Rinse and repeat. For a green field project that is not deployed yet, you can skip step 3) and generated 'baseline' script on first production deployment.

Does exist ORM / Framework that converts data automatically when I want to change column datatype in table?

In the .Net world I've had very good experience with LLBLGen Pro. It supports the generation of DDL scripts to migrate the underlying database to the updated entity definitions. Here is quick start guide that shows the overview of how this works, and here is documentation section for Model-First design process

You can either use it with its own runtime framework, or simply as a design tool for Entity Framework, NHibernate, or Linq to SQL.

Which .NET frameworks allow you to create Business Entities first, then Database

NHibernate supports domain-driven design, persistence ignorance, and automated data-model generation.

Java API for SQL Data Definition Language

DdlUtils from Apache does this https://db.apache.org/ddlutils/

What ORMs work well with Scala?

There are several reasons why JPA-oriented frameworks (Hibernate, for instance) do not fit into idiomatic Scala applications elegantly:

there are no nested annotations as states the Scala 2.8 Preview -- that means you cannot use annotations as mapping metadata for complex applications (even the simplest ones often use @JoinTable -> @JoinColumn);
inconsistencies between Scala and Java collections make developers convert collections; there are also cases when it is impossible to map Scala collections to associations without implementing complex interfaces of the underlying framework (Hibernate's PersistentCollections, for example);
some very common features, such as domain model validation, require JavaBeans conventions on persistent classes -- these stuff is not quite "Scala way" of doing things;
of course, the interop problems (like Raw Types or proxies) introduce a whole new level of issues that cannot be walked around easily.

There are more reasons, I'm sure. That's why we have started the Circumflex ORM project. This pure-Scala ORM tries it's best to eliminate the nightmares of classic Java ORMs. Specifically, you define your entities in pretty much way you would do this with classic DDL statements:

class User extends Record[User] {
  val name = "name".TEXT.NOT_NULL
  val admin = "admin".BOOLEAN.NOT_NULL.DEFAULT('false')
}

object User extends Table[User] {
  def byName(n: String): Seq[User] = criteria.add(this.name LIKE n).list
}

// example with foreign keys:
class Account extends Record[Account] {
  val accountNumber = "acc_number".BIGINT.NOT_NULL
  val user = "user_id".REFERENCES(User).ON_DELETE(CASCADE)
  val amount = "amount".NUMERIC(10,2).NOT_NULL
}

object Account extends Table[Account]

As you can see, these declarations are a bit more verbose, than classic JPA POJOs. But in fact there are several concepts that are assembled together:

the precise DDL for generating schema (you can easily add indexes, foreign keys and other stuff in the same DSL-like fashion);
all queries can be assembled inside that "table object" instead of being scattered around in DAO; the queries themselves are very flexible, you can store query objects, predicates, projections, subqueries and relation aliases in variables so you can reuse them, and even make batch update operations from existing queries (insert-select for example);
transparent navigation between associations (one-to-one, many-to-one, one-to-many and many-to-many-through-intermediate-relation) can be achieved either by lazy or by eager fetching strategies; in both cases the associations are established on top of the foreign keys of underlying relations;
validation is the part of framework;
there is also a Maven2 plugin that allows generating schema and importing initial data from handy XML formatted files.

The only things Circumflex ORM lacks are:

multi-column primary keys (although it is possible to create multi-column foreign keys backed by multi-column unique constraints, but it is only for data integrity);
full-fledged documentation (although we are actively working on it);
success stories of ten-billion-dollar production systems that have Circumflex ORM as it's core technology.

P.S. I hope this post will not be considered an advertisement. It isn't so, really -- I was trying to be as objective as possible.