Is there a field guide to ECC for the IT Security layman? I'm trying to understand ECC from an IT layman's perspective and am trying to separate the theory from the standards, and understand why certain features are implemented or not implemented in the common ECC stacks.

Question

Namely, I'd like to know when should a non-standard ECC library (or related hardware) should be used versus when a standard ECC library should be used. 

Second, I'd also like to know what trade-offs were considered in the common implementations such as DHE in MSFT or Java versus what's implemented in other software



What I think I understand so far:


There are several mathematic properties that can be used in encryption
Many protocols have been created on those properties to facilitate key exchange.  The common standards are broken into the following categories


NIST - Only
The NIST / SECG overlap
SECG - Only
ECC Brainpool

Real world implementation of the above properties and standards are dictated by:


Patent concerns on the math and the key exchange (Certicom)
Security through obscurity (some haven't been released, and some "compatible" derivatives have been created)
Government approval (why did the government approve it? Backdoors, patents, the country that 'invented' it?)

What I haven't been able to figure out is:


Are some implementations faster, more secure, or more suited for (or against) hardware optimizations?
Are some standards preferred simply because a vendor (or government) paid for their patent fees and will not be legislated?

For a given implementation above, is there any risk of (or benefit depending on whose side you're on) of patented techniques like:


implementation of curves over binary fields using normal bases;
point compression;
acceleration of Koblitz curves using the Frobenius endomorphism;
various optimization tricks on dedicated hardware architectures (FPGA, GPU, ASIC).
By non-standard do you mean when to use custom curves? Like in crypto++ where you can specify your own parameters? 

Given that the standards recommend certain sets of domain parameters (and interesting enough US government departments are forbidden from using their own parameters) it's sounds like the answer is no, for reasons of avoiding the risks of self implementation and the worthlessness of "security by obscurity". Tiresome, but this is how i answer all the "should I do my own" question, sorry.

I do know that NIST curves have certain computational advantages over any old curves because there are some just more convenient numbers for the Projective coordinates calculations. Also this wikipedia page seems to think the number of prime curves and binary curves affects security and implimentation efficiency (I have no idea why though, but there is a link in the "NIST-recommended elliptic curves" section )