Need to process $0 transactions while still writing to card on file

So, I have what seems like it would be an extremely common use case, but nothing in the stack people are using to build this kind of use case seems to take it into account.

Specifically, I need the following workflow:

1. Add item to cart, which has two prices: initial price and recurring price. Initial price is $0 for free trial. commerce_recurring and commerce_billing_license support this piece out of the box, in different ways.
2. Check out, provide billing information via Braintree drop-in, even though the first month is free. Store the billing data in the vault, and the non-privileged data (name on card and a few digits of card number, or whatever) and the token, into Card on File. Also create a successful transaction in commerce, because we are wanting a record of this initial order (with 0 price).
3. Bill automatically for the regular recurring price when the free trial is over, using the information stored by cardonfile and the Vault.

The problem is that commerce_braintree (and seemingly most/all) payment gateway types don't support a $0 transaction.

In the patch I've attached, I've introduced a new commerce_braintree_dropin_process_free_transaction function, which is very similar to the process_transaction function, except it doesn't try to get any money and just populates the data structures we need to enter data into the Vault and to create a transaction in commerce so it'll show up in the user's Orders page.

Now, my question is: Am I going about this the right way? I've been suggested No Payment and/or Payment+Payment Basic, but neither provides any means to store card data for later payment, and so are simply not useful. Since I'm using drop-in, I think it *has* to take place within the Braintree gateway module, or some other module that provides the same connections to the drop-in API.

I've attached a patch with a first stab at my solution, which just checks for a $0 value and does the stuff I mentioned above. It kinda sorta works, but it's still very clunky code, with debug messages and stuff in it. I'm just hoping to get some feedback on whether I'm barking up the wrong tree here (no one has suggested changing the payment gateway code, but all the suggestions I've gotten seem to ignore the hard requirement that we collect billing information during the initial checkout and not make the user come back after a month to pay for the subscription to continue).

In short: Can somebody look at this and check it for reasonableness. I'm happy to clean it up and make sure I'm handling the edge cases and such, but I don't wanna tread water on something that can never be integrated in. If there's a better way to implement this, I'd like to know sooner rather than after I've spent days coding it. All that said, it's kinda working. In another day or two, I should have all the kinks worked out, and a fully functional solution.