I am sure that nobody knows the answer to this type of question. My recent script (look for 'e-peen' thread title) was an attempt to help give approximate answers, but nobody much has actually run it yet so we don't have a dataset of how different systems score, nor any confirmation that the script corresponds in any way to real usage. Maybe that script is no good either...
If you have already done this test with 100 people you should be able to work out the number of Moodle php requests per second that this caused. This is the most useful concurrency figure (not number of users - requests per second, and what type of requests they are). Once you have that number, if it was obtained from tests in a similar environment, you can hopefully just multiply by 10 to get your target.
Using this information, you might be able to create a script in a load testing system such as JMeter which makes that many requests to a quiz page of a similar kind. You could run this script against your current server, and any proposed system, to see what maximum estimated requests per second the server can handle.
I don't think there is any real way to evaluate hardware ahead of time because no data exists. At the Open University we serve a lot of requests and (leaving aside things which are only in place for reliability and don't help peformance) we do it with a single fast Postgres database server (iirc it has 16 cores, 64GB RAM), four reasonably fast webservers, and an NFS server linked to our SAN for dataroot [and sessions which is a performance/reliability issue].
With 1,000 people simultaneously taking a quiz, you are probably around or ahead of OU peak load. We typically see about 1,000 different users in a 5 minute period (I looked right now, last 5 minutes it was 964 users) but many of those users are probably just dropping in to look at a course page and see if there's anything new, or they loaded a long forum page and are reading through it - whereas answering a single multiple choice question could potentially be much quicker, resulting in more frequent requests...
--sam