I haven’t tried it myself, but I believe I am familiar enough with both CQRS and Ember Data to address your question.
Ember Data, while it is very extensible, has some assumptions baked in that make it a poor choice for an event sourcing architecture. The “adapter” abstraction is designed around a mutable data gateway, with methods like createRecord(), updateRecord(), and deleteRecord(). You can’t really use Ember Data without using the adapter abstraction.
Furthermore, I find the “store” abstraction is a mismatch with event sourcing. The store is very “place” oriented, where records are identified by ID.
For a CQRS application, I think a better data model would be an immutable persistent data structure, where each event returns a new root node.
With that in mind, let’s turn to Ember proper. I think that this, too, is a bad fit for CQRS. Ember’s “two-way data binding” design encourages (requires?) mutable state. CQRS separates query from commands by definition, but two-way data binding makes command and query two sides of the same coin.
So my conclusion is that, unfortunately, Ember Data’s design and Ember’s two-way data binding feature makes Ember a poor choice for CQRS architectures.