The benefits of this would be being able to demonstrate differences in indexing strategies and constraints. Also, creating views, stored procedures and UDFs for architectural questions.
This would obviously need to be carefully monitored and carefully designed.
If all users have access through a single SQL Azure login, you need to ensure that any user cannot change the password through T-SQL: ALTER LOGIN.
Everyone logging on as effectively the same person makes it difficult for people's work not to be stepped on, since typically ownership of an object you create means you can do most anything to it, and if everyone is logging on identically...
SQL Azure does support DDL triggers, so log tables could be made to keep track of when objects are created. Objects which are around for a certain amount of time could eventually be dropped automatically - however, obviously constraints may stop objects from being dropping in the incorrect order, so dependencies would have to be searched.
Perhaps the database could be restricted to only certain approved users, or perhaps objects could be nominated for moving into permanent demo schemas which demonstrate certain techniques to become part of a canonical data set.
Another possibility is to require users to develop in their own Azure database which the GUI can connect to (as a read-only user with all details supplied by the owner of the database), and then if their work is to be promoted into an official demo space, then it is pulled into the demo space. Thus the user is responsible for their own database, but Data Explorer can connect to it to demo some particular feature.