I haven't been able to find where I said it, but I posted here a while back that I think there's an exception to TDD/BDD, which is when you're hacking experimentally and you don't really know where you're going with it.
I found out this was wrong. Right now I'm coding something maybe a little unusual, which I haven't written before and for which there isn't that much similar code out there. I did my usual mostly-bad habit of half TDD, half informal in-IRB TDD. (Where you know the result you want to see, but instead of putting it in a test harness, you just hit the up arrow a lot.)
Side note: don't expect good writing today. I've decimated my brain with inconsistent sleep and diet. It'll be out of commission for a while.
Anyway. The result of not really knowing exactly what I needed to build until it was built: tons of specs to throw away. And that, I think, is the real relationship of TDD to experimental code. You still write the tests. You just throw a lot of them away. In this instance I built a lot of stuff, to some extent with TDD, that either represented a dead-end, or ended up getting moved into different objects and/or files. So that means you throw away a bunch of specs and you rewrite a few. But you write them, in either case.
The reason I'm confident in this is I took the attitude that you don't need specs for experimental code and ended up with a ton of functioning, untested code in Archaeopteryx. When I realized some of the code was no longer experimental, I had to ask myself: does "experimental code" even mean anything?
No code is ever final. You can always add new features or refactor somewhere. So the idea of "experimental code" is kind of a trick. All code is somewhat experimental, especially if you're still in the process of writing it. If you don't put it in a test harness, it's still an experiment. Using TDD just upgrades the experiment to something that uses the scientific method.