The issue is more annoying than the change of location of the SDK, the path to the compiler has also changed unless users manually install the Unix command-line tools, either using a button in the GUI or by installing a separate DMG.

There seem to be two options to thoroughly fixing this:

1) Tell users they must install the unix tools (cltools*.dmg)

   I'm not 100% sure at this time that this would work, from what I've
   learned from inspecting the installer packages this seems to imply
   "-isysroot /" (that is, no /Developer/SDKS/....)

   A small change to distutils and packaging would switch distutils from
   using "-isysroot /Developer/SDKs/..." to "-isysroot /" when it 
   notices that the system root doesn't exist. This is similar to 
   existing hacks for changing a number of compiler flags on OSX 10.3
   when using the 32-bit universal build.

2) Tweak the configure script, distutils and packaging to look for the
   SDK and compiler in the new location if they cannot be found in the
   default location.

   This would be the most user-friendly as the build would "just work",
   but is more work on our end. I have a 10.8 VM with and Xcode install
   where I haven't installed the unix tools to experiment with this. 

   This is definitely more work than running configure with a
   different SDK and custom values for CC and CXX, we also have to 
   convince configure that it isn't performing a cross-build (it seems
   that some compile checks are performed before we add -isysroot to
   CFLAGS and because I don't have the unix tools installed this results
   in a compile failure early in configure)

   This option might be of limited use though: when you want to build
   an extension that uses a C library that isn't shipped with the OS
   (for example PIL with libjpeg) the build of the python extension
   would "just work", but you'd still have to manually specify the
   compiler and system root for the build of libjpeg.