I'll admit that I am not sure how the bitnodes thing works, but one thing we can be certain of is that it is not part of the bitcoin protocol, so this is completely optional. On the surface, it does not seem sustainable, unless the people contributing the reward money stand to benefit in some way. And if that part is not clear, then the pessimistic little guy sitting on my right shoulder is whispering to me that I should assume their intentions are not entirely pure.
One thing to note about the full node issue is that it is directly tied to the mining.
We all know about the problem of centralization of PoW through the use of large pools (and if you don't know, ask thelonecrouton). Well upon closer inspection, you'll see that the full node issue actually exacerbates this problem. Currently the only incentive to run a full bitcoin node is profit from mining pool operation. So only mining pool operators will continue the necessary expense to keep their hardware "up to snuff" as far as full node requirements go.
As only the richest pool operators with increasingly powerful/dedicated hardware will be able to maintain full nodes, the number of pool operators will also decrease. This effect is quite similar to how the number of individual miners has drastically decreased, but the hash rate and cost of the ASIC hardware has at the same time exponentially increased.
With DASH in its current form, we already have two full-node incentives built into the protocol: mining and masternodes. That doesn't even include users who simply leave their fully synched wallets open 24/7. I know some already do this as "liquidity providers" for darksend mixing, but there is no subsidy for doing so AFAIK.
This brings me to another point: We have many more than 2100 "full nodes" in the DASH network. Anyone with a DASH Core 0.11.2.x daemon or QT open and synced is a full node at that moment. Since we don't have electrum or greenaddress or blockchain.info types of services (YET), everyone using a wallet outside of an exchange is basically going to be using a full node during the time he has it open and synched. Given the nature of p2p, I'm not sure there is an easy way to count the number of nodes at any given time. (I thought that was the main intention of the bitnodes thing. This reward scheme must be a recent development.)
So full nodes aren't really an issue now, but they will be once we start getting more adoption and users transacting via SPV clients, plus with Evan's recently alluded-to plans of A to D transaction abbreviation, I believe we will also introduce a new class of lightweight client that will further reduce the number of full nodes. So what all this means for us is awesome future-proofing...and I didn't even touch the topic of scalability! (I'm sure I'm not the only one eagerly awaiting Evan's proposal for this!)
Regarding masternode hardware,
I think the devs are already on the masternode HW issue. It probably is less of a specific hardware requirements thing, and more of an actual performance returned thing. So you'll know if your VPS isn't good enough because you'll get kicked off the PoSe list. And btw, there is already a built-in hardware requirement: If your VPS doesn't physically keep up, it won't be synced or will crash/etc, and you risk not getting paid. So I'm guessing that even with the current network situation, if we suddenly loaded the network up with services (i.e. everybody starts furiously using IX and darksend mixing, plus whatever other new goodies we may have in the oven), then it's possible that only those with more powerful servers will stay alive. But it will also mean that adoption has gone way up, along with the price and reward for running a masternode. So basically we don't have to worry about the masternode performance. Our friend economics will do its thing.
As far as the number of masternodes goes, i think I recall reading that Evan believes 3000 to be good number, and if he does, it means he probably put a lot of thought into it. There has previously been a lot of discussion regarding this. I don't think there is a difference between 500 or 1000 collateral economically, because the same % of the market cap is still securing the network. Assuming that this rule is also true of the hardware requirements (for example, 2x the total masternodes means 1/2 the current hardware requirements), then the only difference would be the number of unique IPs, I guess. I'm sure Evan and others have already considered the different possibilities here when he came up with the reward schedule.