Yes. My experience with TDD is that it did save time, but not necessarily in initial development. The long-term effect of fewer defects combined with the capability for a higher release velocity is a net savings.
As a counter example, I'm working with a company that uses TDD for their current development, but employees work on a platform with little test coverage. As a consequence of lacking unit tests, they're only able to release a few versions each year because their manual testing burden is so high (estimated by one manager as about half of the cost of a release). They've found that TDD for their new features doesn't escalate the QA cost as significantly as not doing it. Bottom line: it's a little more time up front, but they've found it to be a long-term gain.
The massive upside is that there is much less defects in the end product (think it was 50-80% in the study, but can't recall exactly).
Depending on the project, the extra time needed, might or might not be worth it.
Take a somewhat complex web app, that is used for a marketing campaign. It has a life time of only 2 months. In this case it does not make sense to use TDD, as the lower defect rate and "future-proofing" qualities, might very well not be worth an increased budget.