Here's a patch for review.  It implements:

* a new configure option:

  --with(out)-ensurepip=[=upgrade]
                          "install" or "upgrade" using bundled pip

* a new makefile macro ENSUREPIP that can be supplied to a "make install" or "make altinstall" target to override the configure option:

   make [alt]install ENSUREPIP=[install|upgrade|no]


While testing the above I've identified a number of issues.  I haven't had time to do more than a quick triage on most of them so the initial analyses may be wrong.

Wheel installation issues:

1. Files, but not directories, from the pip/setuptools wheel were installed with a different group id than when installed with pip from a source dist.  (This was comparing the current checked-in wheel file versus a normal sdist pip install of pip, on OS X.)  It appears that the files installed from wheels ended up with the effective gid of the installing process, while those from sdist files had the group id of the parent directory like other files installed by make [alt]install (POSIX allows either behavior but pip should be consistent).

2. It appears that .py files installed from wheels do not get compiled upon installation (no __pycache__ or .pyc) whereas non-wheel pip installed .py files do get compiled.  (See also 7.)

3. The unversioned pip file name differs between wheel and non-wheel installs:  pip3.4 vs pip-3.4.

4. No unversioned version of easy_install is created for wheel installs, only easy_install-3.4.

General pip issues:

5. Various ResourceWarnings about unclosed files and sockets were observed when used with a debug python.

6. Perhaps more a Distutils issue but the files and directories created under lib/python3.4/site-packages use the process default umask and thus may have permissions different from the files installed for the standard library.  The latter get standard "install" permissions because the main Python setup.py subclasses and overrides the default Distutils install_lib class to accomplish this.  Since the Makefile does not know exactly what files have been installed by ensurepip, the install and altinstall targets could only guess at what files need to be fixed up.

7. Other standard library .py files installed by "make [alt]install" are compiled to both .pyc and .pyo versions.

ensurepip issue:

8. "make install" is a superset of "make altinstall" and one would expect the results of (a) "make install" to be the same as (b) "make altinstall && make install".  However (b) results in "python -m ensurepip --altinstall --upgrade && python -m ensurepip --upgrade" which results in no unversioned pip files being installed as the second call to pip does nothing:

Requirement already up-to-date: setuptools in /py/dev/3x/root/uxd/lib/python3.4/site-packages
Requirement already up-to-date: pip in /py/dev/3x/root/uxd/lib/python3.4/site-packages

Perhaps ensurepip module should also set "--ignore-installed" when calling pip?

Makefile:
9. I still need to create [alt]installunixtools links for pip* in Mac/Makefile.in.