I just pushed my organization to pilot an agile approach on one of our projects. It was a challenge for senior management because they need a projected budget and timeline before they can even get a project funded (it's a large enterprise-y company).
So, I did what I always do in that situation, make an educated guess. I looked at the scope we were assuming the project would entail, guessed at the development time of those items, added in some additional time for business analysts, DBAs, project manager, etc., added some padding, and called that the estimated budget. Note that this kind of "rough order of magnitude" estimation is done in my company before every waterfall project as well, so it was no different.
Then, as we started the agile project, and we got a sense of our velocity, we projected the end point of the project based on the velocity and the remaining story points, and found that we are coming in ahead of my original high-level estimates. But that is okay (and we expected it).
So I guess to generalize an answer, it depends on what you mean by "long range", and when you need these estimates. If you need them before the project starts, you can use my method. If you need them during the execution of a project, you can use the release planning concept that Matthew Kubicina mentions.
Also, I highly recommend Mike Cohn's Agile Estimation and Planning book which helps address this kind of stuff.