I'd say that the choice of the payment model has to be figured out very early in the development because it greatly affects the overall cloud application architecture.
Even if one starts with free services and/or by paying (I assume you meant fixed) Azure costs on a monthly basis, scaling up (which is why Azure is the choice for the back-end) will inevitably push people towards shared or reserved instances and, essentially, pay-as-you-go costs.
By the time one realizes that the scaling up implies switching to a different payment/business model because the costs are, after all, per-usage and not fixed nor regular, it will be too costly (or even too late) to go back and try to retrofit into the application architecture a different payment model in order to offset those costs.
In fact, at the moment there does not seem to exist such a model which would match pay-as-you-go on the back-end side.
Speaking of which, I just started looking at the WP8's Wallet functionallity, specifically OnlinePaymentInstrument. Perhaps that can be used as a way to maintain some sort of a user account balance, which can increased with occasional payments (i.e. pay-as-you-go).
The trouble is, there is no equivalent functionality on Win8, but that's a problem for another day.
Azure backend is great, but here is a million-dollar question: which Win8/WP8 payment model does actually support Azure costs which are in their nature per-usage?
Neither a subscription-based payment model nor in-app feature purchases can address the issue of per-usage costs. Why isn't there a pay-as-you-go model that would allow users to purchase some sort of credits, which would then offset Azure traffic/storage costs?
As it stands, there's no point in building WP8/Store applications with Azure backend because it is financially unsustainable business model.