"it'll be done when it is done" isn't the only thing that an agile customer has to go on. There are high and mid-level estimates that give them a general idea. If you're doing something other than SCRUM (like Kanban), you can use cycle time to determine a completion timeline. With a little bit of metrics analysis, you can even provide a probability that you'll be able to meet a particular time estimate.
Two other things that will make a HUGE difference is whether or not you have a committed product owner, and how much control you have over external dependencies. With respect to product owners, people can't just say, "here build this," and then disappear until it's finished. I've been there. It sucks. If there is one reason an agile project will fail, this is it. Product owners need to be fully engaged.
Finally, if the agile project is executed correctly, timelines shouldn't be *that* big a deal because the product owner is receiving delivery of the highest priority features along the way. I realize there are ways that this can be sidetracked (if, for example, the product owner decides that a delivered feature needs to be re-designed because of a faulty assumption), but that's what agile is supposed to accommodate.