Hi,
1) The UnitOfWork is nesting aware. That means it is possible to create a single transaction that deals with commands that cause other commands (via events, usually).
However, it is usually a design flaw if your application really relies in this. In your example, why do you send 2 commands to create a user? Why not send a single command that does the whole job at once? I haven't encountered a single case (yet) where it really wasn't possible to capture an atomic action in a single command (and acting on a single aggregate).
2) You can use the GenericJpaRepository to store your aggregates using JPA (the AbstractAggregateRoot is JPA-annotated). If you want something else, you can easilly create a subclass of the LockingRepository or AbstractRepository. These abstract repositories deal with the UnitOfWork handling for you.
To add transactional behavior to your commands, you can configure an Interceptor. If you use Spring, you can use the SpringTransactionalInterceptor to start a transaction using the PlatformTransactionManager in your spring context. This interceptor will check the UnitOfWork for a success or failure. If you need another type of transaction, you can extend the abstract TransactionInterceptor class. It will allow you to commit the transaction when the UoW is committed, and rolled back when the UoW is rolled back.
I hope this clarifies stuff a bit. If you have any concerns, don't hesitate to let me know.
Cheers,
Allard