I think this is generally a good idea, but the danger is that programs start checking for implementation instead of supported features (or quirks). It's important to make sure that the dictionary definition stays updated with features (or quirks) to prevent this.
See the HTTP User-Agent mess to see what can result if this goes the wrong way.
There's a big difference between HTTP User-Agents and this PEP's sys.implementation. User Agent sniffing is a bad idea because browsers are outside of your control. They evolve while web sites stand still.
In this case, you can control which implementation you run. You can control what software runs on that implementation. You can change both of them. They are both under your control.
Presumably, you can still choose or edit the software you run on it, outside of the corelibs. Also, you can ask them to fix a bug, but you can't ask somebody else's grandma to update her browser.
I think this is a terrible idea. Implementers of Python should code to a unified Python standard, instead of asking programmers of Python to code to a disparate collection of implementations.
This doesn't seem to me to be the goal. I think the point is that implementers would produce this module, and stdlib developers would consume it. Joe Foobar python programmer should never need to know about it.
I think it's maybe not the best solution, but it's good, and the fact that they're trying to address the problem somehow is great.
I suspect this would be most useful in working around 2.6/2.7/3.1 differences and loading different files/polyfills in response, or something. But old versions arn't going to magically retroactively implement a new PEP, so we won't see the benefit for some time. Other than that it's hard to imagine a use case for needing this sort of information.
See the HTTP User-Agent mess to see what can result if this goes the wrong way.