(Disclosure: I am the founder of MongoHQ and obviously would prefer that you choose us)
The biggest difference from the developer's perspective is the ability to query. In DynamoDB, you need the exact key for this document, or you need to create your keys in such a way that you can use them for range-based queries. In Mongo, you can query the structure of a document, add secondary indexes, make clusters, etc.
The advantage of this in k / v is that it forces you to build your application so that DynamoDB can scale. The advantage of Mongo's flexible queries against your documents is that you can do much faster development, even if you reduce what the Play infrastructure includes. It will always be faster to do new developments with something like Mongo, because you do not need to make scaling decisions from the very beginning.
The implementation is reasonable, and Mongo and DynamoDB can grow mostly without restriction. Dynamo solves most storage, RAM, and processor power solutions. Mongo requires that you (or someone like us) make decisions about how much RAM to have, which drives to use, how to manage bottlenecks, etc. The failure of operations is different, but the end result is very similar. We run several Mongo DBs on top of very fast SSDs, and this works phenomenally well.
Prices, unfortunately, are difficult to compare. DynamoDB pricing is based on face value per GB, but you pay for data access. You must be sure that you understand how your expenses will grow as your database activates. I'm not sure that I can effectively forecast prices for DynamoDB, but I know that we had customers who were surprised (at least) by how expensive Dynamo was what they wanted to do.
Running Mongo is much more predictable in cost. You will probably need 1 GB of RAM for every 10 GB of data, running over-tuning doubles your price, etc. This is a much easier equation to wrap your head around, and you are not too nasty to shock if you have a huge amount of traffic for one day.
The biggest advantage of Mongo (and MongoHQ) is that you can leave your provider at any time. If your Mongolian provider annoys you, it will only hurt you to migrate a bit. If Amazon annoys you, you will have to rewrite the application to work with a completely different engine. This has huge implications for the support you expect to receive, since Mongo's hosting is quite competitive, and you will get very good support from any particular Mongo company that you have chosen (or we will die).
I turned to scaling a little higher, but the simplest answer is this: if you correctly define your data model, any option will scale as much as you can imagine that you will need to go. Most likely, you most likely will not do it right with Mongo, because you are probably developing fast. This means that if you can no longer scale vertically (by adding RAM, disk speed, etc. per server), you need to be careful how you choose the fragments. The biggest difference between Mongolian and Dynamo scaling is when you choose “how do I scale my data”? solutions, not general scalability.
So, I would choose Mongo (duh!). I think you can create a fantastic application on top of DynamoDB.