I mean, when I use Django, even though I could switch out the ORM, I'd be ditching a lot of freebies (integration with auth, forms, South, all the reusable apps in the wild). Thus, you really don't see people ripping out the Django ORM except in the very extreme cases. It also explains why it'll be really difficult to switch out the Django ORM, as there is just so much integration to rewrite and legacy apps to lose.
If I wanted/needed/was willing to reinvent all of that, I'd probably start with a smaller framework (like Tornado, Flask) where the only stable game - so far - is SQLAlchemy.
Thus, I don't think it's in your benefit to consider/advertise yourself a lightweight alternative to the Django ORM, as there aren't many folks looking for an alternative (and even though most people aren't 100% happy with Django's ORM the bar to competing is really high). Your users are most likely not using Django, and deciding between Peewee and SQLAlchemy.
But that brings me to my point. Do we need to keep running after abstraction (ORMs) when the needs become sufficiently complex and the abstraction ends up making things more opaque ?
ORMs are great for simple stuff. Raw SQL rules for complex stuff. Yes/No ?
Often I avoid putting any work on my db beyond filtering and grouping of results. Its typically much easier to scale out app/web servers than it is to scale out databases to support a heavy query workload.
I do think it would be nice though to get rid of things like Q objects and move to something else. Maybe something such as objects.filter(text='hello' | text='goodbye'). Either way Q objects are extremely useful and the Django documentation does a nice job of showing how to use all the queryset features.
We were layering some web stuff on top of a database that worked flawlessly with SQLAlchemy and ended up changing our data model to accommodate Django's weaknesses.