Feel free to quote me on this later, but I think that would be a huge waste of time and effort. If it comes to it, later (much, much later) we could build some bridges between our application and other applications but I don't see it as an essential, or even useful, thing to work towards right now.

Other SQL comments:

• For the primary keys, use unsigned ints. Why allow for, but never use, numbers from -2147483648 to zero?
• users.user_pass doesn't need to be VARCHAR(255). Depending on what hashing we'll be using, it can be CHAR(32) or something like that.
• It might be worth making item_comments.item_comment_text bigger, 255 chars might seem more than enough (cf. Twitter's 140 limit) but should we really rule out those commenters who like to write long, thought-out messages?
• Maybe I'm just being blind, but I don't see a common key between the items and item_comments tables.
• Perhaps consolidate multiple tables. A subscription is a subscription, why have two tables for essentially the same thing? If we later want to allow many different kinds of subscriptions (follow comments for a user, item, album, new items from a user, in a album or gallery...) would we need a new table for each of those? The same goes for the *_comments tables.
• Standardise the naming. Some tables are plural, others not. Some columns underscore-delimited while others mix with camelcase. Personally I'd drop the table name prefixes for the columns too: gallery_rating.gallery_rating_gallery_id vs gallery_rating.gallery_id

Sorry for being so nitpicky!