Try to structure your service with monthly allotments. So instead of a total of 5GBs, allow 1GB per month.
Also, from an implementation perspective; make sure that to run an upgrade/downgrade all you need to do is change some database field values. You do NOT want to be running code that has to go through and change a bunch of stuff.
For users... keep them around; just disable their login. We're going to be implementing multiple users in our application and we are going to handle downgrades by simply maintaing an "ordered list" of users. So you have 20 users on your account w/ 20 max in that plan. If you downgrade to a 10 user plan, we "gray out" and "disable" the "bottom 10" users. The administrator can rearrange the disabled users towards the top of the list, which will "re-enable" them.
This raises another important point with our approach; we keep all of the users data so that when they downgrade, they can see that all of their shit is there but some of it might be disabled (don't hold your users data hostage or they will get PISSED! Note how for our users approach we don't just disable users willy nilly. The admin/user has control). If they can see their data is there, just not "usable" w/o an upgrade... they might be tempted to upgrade again.
Good luck implementing all of this! It truly is a pain in the ass. Just keep it all data driven and your life will be much easier.