Just to clarify and confirm @bernatgabor:
Python installed in a default venv will still look for system wide installed sitecustomize modules (in the main Python lib dir, not in the system site-packages), first in the system dir, then in the venv site-packages.
It only looks for usercustomize modules in case user local site-packages are enabled for venvs (which can be done via the system wide sitecustomize, but only has the effect of enabling usercustomize import – not the user local site-packages as one would expect). This is then also searched in the system dir and then the venv site-packages.
Now, in order to get access to the OS packages as mentioned, you’d create the venvs with --system-site-packages. In that case, you can also place the sitecustomize module into the system site-packages, since that’ll be on the sys.path as well.
This is only for venvs. The situation is different for regular calls to the system Python. I haven’t checked how virtualenv (the original tool) behaves. It all gets even weirder once you start to define PYTHONPATH as env var 
The logic around all this is highly complex and not necessarily intuitive. It’s codified in site.py.
@mariocj89:
What I meant is that you need to be able to have multiple __pycustomize__
dirs, which then all get scanned in order to maintain the logic we have for the different invocation scenarios. One dir is not enough to emulate both sitecustomize and usercustomize, since you may well have the case that packages are pulled in from multiple directories on the sys.path at various levels of the directory hierarchy (system level, user level, application level, etc.).
Of course, you can argue that usercustomize is no longer needed with venv et al. and I wouldn’t disagree
site.py has grown much too complex over the years and what may have been useful 15 years ago, may well no longer be needed.