Is there any benefit of using an interface simply because a group of objects share a couple of public methods?
For example, I have GameObject, GameComponent, and GameLevel. Each have functions onUpdate() and onDraw().
Should I create an IGameEntity interface that contains onUpdate() and onDraw() and have each object implement it? I don't have an intention of storing any kind of list of IGameEntity's or any similar situation where I only need access to those two functions, so is this level of abstraction constructive?
You probably don't need to bother, as you can refactor it later if needed. (Unless the code is part of a public API, in which case its users should be considered.)
Interfaces are meaningful constraints on types. Generally, I'd say that an interface called IGameEntity sounds questionable. What is it? From its functionality, it might as well be called IUpdatableDrawable, but this name already shows that it would be an oddball. It is sometimes necessary to introduce concepts like this, but this is a cost in terms of readability that should only be paid with good reason.
A good interface gives a name to a set of features that belong together. Just like in spoken language, there's little point in naming a concept without use cases.