Update: the MacPorts certsync daemon has matured and is now included as
an optional MacPorts port.

It's not a perfect solution as noted in the macports-devel thread:

>>The only catch is that custom added certificates or trust anchors need
>>to be in the system keychain to be picked up by certsync by default.
>Yeah, this was an unfortunate trade-off; since certsync is a system-wide 
>daemon, and the resulting CA certs file is also system-wide, it seemed to
>be the most appropriate course of action. Most of the alternatives involve
>patching OpenSSL and some of the software that depends on it, which is a
>road I'm personally wary of committing to.

http://comments.gmane.org/gmane.os.apple.macports.devel/22653

It works by registering a launchd agent that is run whenever any of the
system keychain files or trust setting files are modified.  That raises the
issues of when and how a Python install should register the agent (will
likely need admin/root privileges to do that) and how to delete the agent
(we currently don't have a formal uninstall procedure on OS X).  It would
be easier to manage these things with the binary installer-based Pythons,
as provided by python.org, in which case Pythons built by users from source
would still use the deprecated Apple-supplied libssl and libcrypto.  But
I'd like to separate out the building of third-party libraries, like
openssl, from the installer build process so that user source builds can
take advantage of features like this.