In an application with an entry point of __main__.py, multiprocessing.Pool throws the following:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "D:\Dev\Python27\lib\multiprocessing\forking.py", line 346, in main
prepare(preparation_data)
File "D:\Dev\Python27\lib\multiprocessing\forking.py", line 454, in prepare
assert main_name not in sys.modules, main_name
AssertionError: __main__
These messages repeat as long as the application is running.
Demonstration Code, must be in file named __main__.py:
--------------------
import multiprocessing
import time
if __name__ == '__main__':
pool = multiprocessing.Pool()
time.sleep(2)
--------------------

I wrapped the offending assertion in a if main_name != '__main__'. I considered not checking the module_name against built-in modules but that seemed likely to be the sort of thing being guarded against, so I left it at an exception for __main__.
Ran a few trivial testing using Pool and Process and it seems to work fine.

Marc's reference to pip meant I noticed something that I had missed previously - that this issue is referring specifically to the use of setuptools/pip entry points, not to the -m switch.
Entry points shouldn't be hitting this if they're importing the module containing the entry point normally - #10845 specifically related to invoking multiprocessing from a module run directly with the -m switch, which was worked around in 3.2 and 3.3, and then finally fixed properly in 3.4 by the implementation of #19946
So if there's an incompatibility between multiprocessing and entry points, it would be preferable to fix it in pip/setuptools, as that will reach many more installations than just fixing multiprocessing to better tolerate that situation.

Thanks for the investigation Marc.
I'd been hesitant to backport the mitigation patch in #10845 to 2.7.x, (as it *does* represent a behavioural change), but if that code path is currently hitting an assert statement anyway, it seems reasonable to make the change for 2.7.11+