With the exception that we have control over the Python core code while we don't over third party extensions, so providing means to simplify the transition for the standard lib is easier than trying to enforce your proposed 'nonstd' package.
I think you could get a long way with minor changes along the lines of making site-packages a package itself.
Then please think about a proper solution rather than proposing something whose only virtue seems to be that you can implement a poor approximation of it in two lines.
Just testing waters here... there's no point in trying to find a solution to something which is not regarded as problem anyway.
You started by claiming that there's a problem: expansion of the stdlib could conflict with 3rd party module/package names.
I don't regard it as a problem that's so bad that we need to make big changes to solve it.
If you still think a solution is desired, you could start by proposing a new standard package hierarchy. Then new standard modules could be placed in that new hierarchy rather than at the top level.
I'm rejecting the proposal of a single top-level package named "python".
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)