The reason boost::signals doesn't already do this is already is documented
here -- those figures only include trying to autohandle const and non-const references, trying to automate when placeholders should or should not be introduced in a generic way would be even worse, unless you special case it as an all-or-nothing type of thing (in which case you're still looking at 20 overloads).
You're also missing a version of connect for functors -- meaning you can't manually use boost::bind with your class, currently. boost::signal<>::connect also returns a boost::signals::connection, which can be useful. You don't have scoped_connect()ions, [scoped_]disconnect()ions, etc handled... easily another 60 overloads, even for your all-or-nothing approach... for a total of 80 already.
Now, the additional reasons that I haven't done something like this myself:
1) This is a lot of work when the improvements only touch one library (which is how it will have to be to eliminate the manual call to bind). I spend a lot more time using boost::asio, for example -- this wouldn't help me at all there, but will still increase my compile times.
2) In the end, you're not really eliminating all that much. Your final construction will probably be more code than you ever end up writing as bind statements. You're really not eliminating much after all: bind(,_1,_2) <--- the sum of all eliminate-able text right there, with your current code, which is literally less than 1/100th of the code in your current Signal.hpp alone, even with all the stuff I've pointed out is missing.
3) In the end, you're actually
writing a lot more. boost::bind is battle tested, is already debugged, and works. Your Signal class isn't -- nor would mine be. It's also another thing that would need to be maintained and understood.
I'm not saying don't do it -- you may have good reasons for doing it -- but just to list some things to keep in mind if you find yourself tempted to let runaway feature-itus take over.