Is this a decent way to create an EntityManager?
Ahhhhhhhhh
static EntityManager* instance();

No ownership associated with even the manager.
If I get a manager. Who is responsible for destroying it?
// Do this.
// Use the classic singleton pattern.
static EntityManager&amp; instance()
{
     static EntityManager   managerInstance;
     return managerInstance;
}

https://stackoverflow.com/questions/1008019/c-singleton-design-pattern/1008289#1008289
Who owns the entity?
void registerEntity(Entity* entity)

Is the manager supposed to take ownership. Which means it will take responsibility for destroying the entity? Or are you giving the manager a reference it can use but does not own (thus it will not destroy).
As it stands. This is completely the wrong way of doing it. Once you tell me how you want to define the semantics of the interface I can tell you how to proceed.

Update The manager is supposed to take ownership.
So lets continue:
void registerEntity(Entity* entity)
{
    entityMap.insert(std::pair&lt;int, Entity*&gt;(entity-&gt;getId(), entity));
}

From the interface you can tell that the manager takes ownership. As a result it can easily be called like this:
Airplane    airplane;
EntityManager::instance()-&gt;registerEntity(&amp;airplane);

Now what will happen in your code. I suspect it will blow up at some point in the distant future. Try tracking that bug down.
The way to do this is to tell the manager he is supposed to take ownership. To do this your interface is supposed to take a std::unique_ptr. Also a couple of potential bugs to watch out for. Somebody may pass you a NULL in which case calling getId() is going to generate undefined behavior (by that I mean crash).
int registerEntity(std::unique_ptr&lt;Entity&gt;&amp;&amp; entity)
{
    if (!entity.get())
    {    return -1;
    }

    entityMap.insert(std::pair&lt;int, Entity*&gt;(entity-&gt;getId(), std::move(entity)));
    return entity-&gt;getId();
}

Notice I am moving the smart pointer into the entityMap. This shows that you are moving ownership into the map. It must also be smart enough to hold the smart pointers. So you have two options:
std::unordered_map&lt;int, std::unique_ptr&lt;Entity&gt;&gt; EntityMap;

Alternatively boost has a pointer container library, where the container takes ownership. Unfortunately they don't have unordered_map but they do have map.
boost::ptr_map&lt;int, Entity&gt; EntityMap;

Using the boost pointer containers has the advantage as access to the elements in the container make them look like objects (not pointers) thus using with any of the standard algorithms is trivial (Note: using algorithms on normal containers that hold pointers is a pain because of the extra de-reference involved).
Anyway either technique will remove the problem of memory leaks.
No check for NULL. Also I see no advantage of having this interface when the previous one void removeEntity(int) does exactly the same thing and does not have the disadvantage of ownership semantics.
void removeEntity(Entity* entity)
{
    removeEntity(entity-&gt;getId());
}

Returning a pointer here:
Entity* getById(int id)
{
    return entityMap.at(id);
}

Does this give you ownership of the object back?
I would think not. If you return a pointer you open yourself up to the user being confused and deleting the pointer.
Entity* plane = EntityManager::instance()-&gt;getById(12);
// WORK on place
delete plane;     // BANG

So return a reference to indicate the caller is not getting ownership back. This does open the question of how do do you handle values that would have returned NULL previously. I would handle this by having an existence test. So for ID that you are not sure about you can validate before a retrieval.
Entity&amp; getById(int id) const
{
    return *entityMap[id];   // de-reference the smart pointer.
}
bool checkById(int id)
{
    return entityMap.find(id) != entityMap.end();
}