Well Pygame itself is essentially a Python wrapper to SDL calls. I think in essence you would just be wrapping a wrapper.
You could always build your own adapter API, but what in particular about Pygame's API do you dislike so much that you feel you need to separate it from your code?
I think your generic methods, like custom collision detection, could be separated out into its own engine module, essentially separating it from the rest of your game code, but essentially you are just layering on top of Pygame with this approach, not wrapping it.
EDIT:
Just as a follow up now that the question has changed. Short answer, no I'm not familiar with any. You may want to check out The Independent Gaming Source forums, those people seem fairly knowledge. Just make sure you post any answers you find back here.
Long answer, it could be possible that the "engine" space between the Pygame, which handles calls to SDL and I think some additional logic (like collision detection), and the game code itself is too small a space for anyone to write a generic library for it. Essentially different types of games have different engine requirements, and the generic parts of the engine that are shared across all game types seems to be covered by Pygame itself.
If you have written an RTS game in Pygame then you certainly could separate the RTS engine from your game logic, it would probably help your overall design by separating concerns. Also, it may be worth releasing that engine piece so that other people wanting to write a RTS in Pygame could benefit from it.