The way i’d interpret the developer policy - and if i’m understanding it right - it goes against points about sharing tokens and using different tokens for the same purpose (1.a and 6.e.i).
BUT: if you implement the registration part a little bit differently, it shouldn’t be a problem:
During registration user input his own Twetter API Keys from one of his Tweeter Apps
You shouldn’t do this - instead, you should create an app for your web service, and then make users sign in with twitter, collect the access token & secret from each user that registers - and store that for later.
This still means that each user has their own rate limits, because rate limits are per user. So your server will still be doing all the querying - but signing requests with Your Consumer Key (API Key) & a User’s Token - this way won’t be against any rules (as far as i know)