Would key stretching help mitigate concerns with "verifiably random"? Daniel J. Bernstein (and others) have expressed concern over how "verifiably random" curve parameters are generated.  He points out that hashing a public seed doesn't prevent, say, the US government (NIST/NSA) from choosing a seed that produces parameters with a one-in-a-million weakness that is not yet known to the academic community.

If the seed were hashed iteratively instead of just once, would this help address these concerns?  If my thinking is correct, iterating a hash function $2^{40}$ times on the seed when producing the standard should make one-in-a-trillion weaknesses mostly infeasible and one-in-a-million weaknesses much more difficult.
No, not really. The problem is that these kind of parameters may themselves be chosen deliberately. In other words, NIST/NSA may have performed a pre-calculation to make sure that the key stretching outputs a value that opens the algorithm up to some kind of attack.

Lets take an example, would you trust: SHA-256^2^40("Trust me, I'm an innocent string?"). Is that more or less secure than SHA-256^2^40("Trust me, I'm an innocent string"), i.e. without the question mark? How would I know that e.g. NIST or the NSA didn't do a few of these calculations up front to create their preferred output? the amount of iterations may be varied as well.

It's probably easier to secure the input of the hash. If they would say to a group of trusted experts: you all jot down a string, then concatenate them all (ordered by last name), and finally SHA-256 the ASCII string then the output is determined by the aggregated input of the experts.

The Brainpool curves were created in a controlled environment, which makes them more safe - according to DJB - than the NIST curves. Of course this is still less secure as not having to pre-determine any input values. This is the road taken by the highest level safe curves.