You're right, I could just rename Sprite to Widget and my object hierarchy would suddenly make sense. In Qt for example, widgets can be nested. But I just thought it felt wrong to call it Widget, since I'm after all working on a game here... There is a lot of UI, but there's more, and I don't want the UI to dominate the terminology in my code base. When I add characters moving around, they would probably end up deriving from Widget...
What is a Widget? What inextricable properties does Widget possess? If it's synonymous with Entity, like Sprite was, then the answer is probably "nothing." A Widget on its own carries no inherent properties. You're almost always going to end up having an invisible Widget, or a Widget that doesn't care about input, or that can't move, or has no position, or has a position in 2-space instead of 3-space, etc. etc. To me, this just says that trying to fit your game objects into a hierarchy is a bad idea, they're not concrete enough. That's why the component based approach has caught on so well, it fits the problem space much better than a more vanilla approach to OOP.
If you broke your current mental concept of Widget out into a class that could be contained and used by any game "Entity", then you could share the provided functionality between both typical "game entities" and GUI elements with none of the troubles of making this work via inheritance. For instance, an in game character and a button could both be Entities that contain a "Clickable" or "Inputtable" component. Some InputDispatcher class is aware of these components, and dispatches input events to them, possibly after filtering the input into some nice format or sending only events that a particular component has said that its interested in.
I think I'm mainly struggling with how I can have my UI (screens and widgets) fit into the same object system as my entities and scenes.
I've faced the same problem. What I did is model Button as an entity that contains Drawable, Inputtable, and Positionable. Some properties set in Inputtable say that it's only interested in hearing about click events, and some properties set in Drawable say that it should be drawn relative to the screen, rather than the world, and some properties in Positionable give it a greater z coordinate than anything else in the scene (so that its always drawn on top.)
FWIW, I wrote a little about component based entity systems years ago, which might help to point you in the right direction.