sending commands from event listeners is something that Axon should support. It’s actually a quite common practice, to be honest. Usually when you fire commands from an event listener, the latter is called a saga. Explicit support for saga’s is on its way.
I created a small application context, with a flow quite similar to the flow you have. It has an asynchronous processor and a default commandbus, event bus and FS event store. I could dispatch the command without problems. Bot with a normal event listener and an asynchronous one.
Did you migrate to 0.7-SNAPSHOT? If so, you shouldn’t need to care about creating a UnitOfWork. The command bus does that for you (and it can even cope with nesting). So I’m afraid I can only report “works on my machine”.
I am not sure if this was the point that Seamus was making, but the creation of a verification token is a business rule. Typically, that means that the aggregate that creates a user will also create a token en send an event that a new (but unconfirmed) account has been created. You can then confirm that account using the token known by the user aggregate. The fact that you’re sending a command towards a user based on an event by that same user is an indication that you’ve got business logic that should be included in the aggregate itself.
The email mechanism would just have to send the token from the received event to the user (whose email address is in the event too). That’s a good example of an asynchronous event listener, by the way!