Personally, I'm still learning how to bill my time out properly. I've got a serious case of underestimatitis. Maybe Craig's numbers will help me understand how much time I really spend on a project.
The important part is not that the estimates match any number of hours per se, but rather than the relative weighting is about right, such that something you estimated as 3 points is, in actuality, about 3 times as much work as something estimated at 1 point, and all 1 point stories are roughly comparable in terms of work.
What you then do is to empirically estimate the actual mapping of points to hours/days as you work by tracking your velocity. In a 40-hour work week, how many points do you actually get done? As you get better at estimating, ideally your velocity becomes more stable, and then you can map from points back to days in order to make scheduling decisions. We switched over project planning and estimation to that strategy on a fairly large project I was leading, and it helped give us much more accurate overall estimates.
Now, that's all easier to do when you're working on a long-term project, you're familiar with the existing code base and the problem domain, etc. such that you can actually break things down into stories and do reasonable estimates.
That said, I think that the general idea of point-based estimation is still useful for you: rather than trying to estimate hours or days, work on getting better at relative estimation using something like points, and then empirically measure your mapping from points to hours to determine your likely schedule and how much you should bill.
That being said, the larger the project is, the greater the probability of underestimatitis. As soon as you hit 250+ hours, I've found estimates to become increasingly less accurate.
The original estimate someone put forth for twitterific was 160 hours of development. Ask yourself, could you reasonably expect to sit down today and from scratch, have written something as polished as twitterific, in only 32 days? Knowing full well you will need to spend days banging your head against some problem that should have taken you 10 minutes but somehow cost you 6 hours, testing and fixing bugs, profiling and optimizing slow code paths, polishing interactions, tweaking animations, and going back to the drawing board when some piece of functionality doesn't quite feel right?
The testing and tweaking alone can last for weeks in high quality projects, and 32 days only gives you 4.5 weeks from start to finish. It's absurdly low.