I'd say that this would typically be measured in a
test or development environment. You create a
representative sample of data for, say, 1000 users, measure the increase in database storage space, multiply it by 500 to obtain figure for 500,000 more users and add some cushion for unexpected variation of your data (at least 20%, but perhaps 50%). The data must be representative - number 1.0 takes less space in the Oracle database than 1.000001, for example, which would be a problem if you used approximate numbers instead of real world ones.
You should also let your application run for some time on the environment you're running the tests on, because indexes (and to some extent even tables) typically grow a bit after being created afresh due to updates and deletes, which leave "holes" in them.
If your application keeps historical data, you should similarly measure how much your database grows every year and factor this into the database sizing as well (so you'd say to your customer that your application needs 5GB of storage space every year).