There's obviously a demand for a recurring payment system. In my opinion, there are two ways to implement such a system. One is a change to the bitcoin base client itself so that, with explicit authorization of the user, it will send x address x # of bitcoins each x number of days. That kind of implementation would probably have a better chance of getting implemented than something that pulls money from the bitcoin wallet since that kind of action defies the anonymous (and fairly libertarian) nature of bitcoin.
While it's possible that it could be it could be implemented, in my opinion, a better way would actually be to create an API to do this. DeathAndTaxes had a good outline of what such an API would need to do.
My idea of it is somewhat different, but builds on what DeathAndTaxes said. The email reminder would be essential if it's going to be a "push" payment rather than an automatic "pull" payment.
I put this in a bitcointalk thread, but this is really a better place for it.
Here's my idea for an API:
1) Customer submits initial payment for x bitcoins. Future payments are then pegged to the exchange rate for x bitcoins to x dollars (or whatever currency the merchant uses).
2) The service asks for authorization for "recurring billing"
3) If the user accepts, a recurring payment schedule is setup. Email reminders are sent out for payment like DeathAndTaxes said. At the 30 day mark, service is shut off if user has not paid. This could be an automatic thing, or more likely, the API would contact whoever is implemented it that x user hasn't paid and thus needs to have x service disabled.
Actually, another way to implement recurring payments that would make a lot of sense would be with a deluxe wallet client like Armory and not touch the base bitcoin client. In a way, this type of implementation would make much more sense than the API implementation because it can be totally recurring without the user having to do anything other than ensure that the proper amount of bitcoins is in his or her wallet and that it's not an offline wallet. The problem with this type of implementation, of course, is that it would limit recurring payments to Armory (or whatever other wallet client implemented it).
Over time, I wouldn't be surprised if both types of implementations occur. I don't see any reason why they can't both occur at the same time.