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.
I think two techniques are key:
Develop a complete simulator or test-environment for the hardware, so that you can develop the software as if you have real hardware. Don't skimp or take shortcuts here: developing a good simulator will pay off.
Write lots of unit tests against the simulator.
Once you have these things going, and people are confident that the simulator and unit tests will give an accurate idea of how things will work with the hardware, it will be easier to adopt other agile techniques (short iterations, relentless refactoring, etc.).
Best Answer
Yes.
False.
When you don't have all the requirements it's the only way to make progress. Anything else requires fanciful assumptions that will eventually be proven false. Agile simply makes fewer fanciful assumptions.
When you have all the requirements, you must still follow all the Agile principles.
Read this before proceeding any further: http://agilemanifesto.org/
All of these points are true no matter how much you know of the requirements.
You still benefit from using an Agile method like Scrum, because you'll have more realistic expectations.
What a terrible first iteration.
Yes. You create the database incrementally.
You do everything incrementally.
You prioritize based on what creates the most value to users. Not fanciful (and silly) technical considerations.