Reinforcing what @davitenio and @byorgey, bugs are a lot more "costly" to me than waiting a bit longer for features at this point of my use of beeminder. Beeminder is my nailgun, I have to spend a lot of time and effort and experimentation figuring out where to put the nail (setup up my goal and metrics), but beeminder "just working" as I expect is a wonderful feeling. It allows me to have firm confidence that once I know the goal structure I want, I can put it together simply and effectively.
Now mind you, the fact that beeminder has AWESOME customer support mitigates this a lot, and so for me, this isn't something that would cause me to stop using beeminder, but it is sometimes annoying, just as @byorgey said.
Personally, I'd have a lot of fun being able to use beta features in some sort of sandbox. My career started out in software and system testing, so that's a lot of fun for me, if I can have a separation between that and the goals that I'm actually struggling to complete and need the "nailgun" type tool for.
Another thing I just realized, with the $810 commitments, is that you're acting more like StickK than beeminder. Large payoff, binary committed things. I think that's a bad example to give users, especially when you could show-off the power of beeminder by tracking code checkins for the feature, or time, or number new tests passing.
Finally, for me, having something like a fever chart (and critical chain schedule) to measure milestones would be how I'd track output, rather than committing to it directly with a beeminder goal. But if you have the other stuff in place, this may not be needed. It depends on how worried you are about rabbit holes and how much transparency you need/want to give into your development processes.