OK, these are a lot of questions for one answer, and I think I can probably only hit two of them.. but here it goes:
FIPS 140-2 Level 2
The FIPS 140-2 requirements are centered around how keys are managed, protected, manipulated and stored. For reference, I'm reading the Security Requirements from the NIST site.
What I'm seeing is that in the transition from Level 1 to Level 2, the standard adds requirements that relate to the physical storage of key material - most strikingly tamperproofing on a physical level. The requirements move from working in Level 1 where the key storage could be software, to requirements where I can't see any way that you could hold the keys in the memory of a standard PC or laptop - you have to have a protected physical location for the key material.
That's not to say that the protected physical location has to be a $10,000 HSM - if I'm reading the Validated Cryptographic Modules list right, there are a few cases in there where vendors of what appear to be SmartCard based products are validated all the way to Level 3. Certainly some SmartCard products provide tamper evidence.
From my experience, when you are operating your key store in software, you can't really call the overall system a FIPS 140-2 level 2 solution - because you can't give that tamper-proof evidence strongly enough. But you can get software modules that can "operate in a FIPS 140-2 Level 2 mode" - meaning they will interoperate with a device that can provide tamper evidence at this level and the module will do so in a standards compliant way that doesn't move the key to any place it shouldn't go.
To try to nail down the question - if you can find a FIPS 140-2 level 2 compliant smart card product (and I think you can), you can make a lower-than-HSM cost solution work, but you have to realize that the SmartCard will need to be present whenever you want your solution to do crypto operations - because taking the keys off the card will destroy the purpose of tamper-proofing. So I'm not sure you're going to get to "Key loading using an Smart Card reader" which to me implies trying to get the protected keys off the card.
Alternate Standards - CC-1 and EAL 5
I'm a little confused here as these are not exactly the same thing. EAL 5 is for a fairly stringent level of verification that a product meets its defined security behavior. But it's not the same thing as the key protections provided by FIPS 140-2. Frequently, I've developed systems that have had to use both, because they offer different types of assurance. Having a really high EAL level will protect you in different ways from having Level 2 FIPS.
I'd be very reluctant to recommend interchanging these - you need to design a system that protects itself to the level of the risks in the environment and the value of information/operations it protects. Swapping between standards isn't going to do that - security analysis will.
Intranet or standalone
This really has to be based on the needs of an application. Where you situate it, how you control access, what purposes Intranet or local users will have for it, and what you need to protect will dictate where you put it and what protections you need for it.
Certainly, the more accessible you make the application, the wider your surface area for attack will be. But online systems may also be easier to update and maintain, and if availability in a crisis outweighs inaccessibility in case of attack, then online may well be better than standalone client.
I'd be wary of advice on this point that didn't stem from a fairly comprehensive discussion of your purpose and product.
