Flexible generic event system that binds to objects
It looks good to me. The Event_Receivable thing looks like a vanilla observer pattern, which involves inheritance. I don't really have comments on the architecture, but I recommend a look at this Game Programming Patterns chapter if you haven't already.

Code review

A few considerations on the design:


The first thing that jumps to the eye here is the heavy use of raw pointers. The event queue, for instance, has a vector of Event_Receiver pointers which it does not own. It would be a disaster if one of those objects were to be deleted while the pointer is still in the queue's vector. Event_Receiver also keeps a raw pointer to its owner. I think you should take a step back and rethink this. It can save you a lot of headache on pointer debugging in the future, not to mention the potential for memory leaks, which can be a serious problem in a game. If you can use C++11, then consider the standard smart pointers. It seems that a combination of shared_ptrs and weak_ptrs would be suitable here.
You already know this, but when you do decide how to handle copy/assignment, take a look at the Rule of Three. The safest course of action until then would be to make the types that hold naked pointers, or arrays of pointers, non-copyable, by deleting the copy constructor and assignment operator. That might actually suit your needs and it is very easy to do.
You are using strings to define the event type and name/id; not sure if this is a good approach. The only reason I would chose to represent those as strings would be if I had the need to create event types dynamically during runtime. The two main issues with using strings are 1) performance: it is much faster comparing an integer/enum-constant than it is comparing a string; 2) when declaring/referencing an event in the code, if you mistype a string, you will only find out about the error after a little runtime debugging. That problem goes away with compile-time constants. Your choice should really be based on how flexible you need the system to be, then choose your trade-off.


Miscellaneous:


Your get* methods are missing const at the end, which would make it impossible to call one of them on a const object. Since they don't mutate member data, make them const correct. E.g.:

boost::any get_info() const { return info; }
                      ^^^^^


Still talking about the getters, I'm not sure how costly it is to copy, for instance, a boost::any, but if the caller will mostly just be inspecting the value, then consider returning complex objects by const reference. E.g.:

const boost::any &amp; get_info() const { return info; }
^^^^^            ^            ^^^^^

Looking in the repository link, I see that you have some very long-winded for loops in Event_Queue, such as this one from Event_Queue::poll_input():


for(std::vector&lt;Event_Receiver*&gt;::iterator it = receiver_list.begin(); it != receiver_list.end(); ++it)



Such huge line can be made a lot simpler by using a range-based for loop (C++11), or at least the use of auto for the iterators.
Event_Sender seems to be missing a constructor, which would leave its member pointer uninitialized until it is set somewhere else. This is very dangerous and can be a source of bugs. Always initialize your variables to a known value. Don't leave room for chance.
Looking at the implementation of Event_Receiver, the destructor is empty, so you can just remove it and let the compiler supply a default.
You have a mixed style of public/private class sections. Some have private at the start, others have it at the end. I'd suggest that you make it uniform through all classes. My personal preference is to place the public section of a class first in the header file. The rationale is that people using and reading my code will care much more about the public methods and data, so that's what they want to see first when reading the header file. Private/protected sections of a class are of interest to the programmer maintaining the code, so it makes sense that they don't need that much visibility.
Use the constructor initializer list to init member data. Using the assignment operator might result in redundant initialization if the compiler is not able to optimize the code (calls the default constructor of a type + operator =).

Event(std::string name_str, std::string type_str)
    : name(std::move(name_str))
    , type(std::move(type_str))
{ }


That's also a perfect place for a move, to avoid copying things over and over. Without move the best would have been taking name_str and type_str by const reference.