I know I'm late to the game here, but for the members table:

• nickname VARCHAR(25) PRIMARY KEY, - Nickname, again, not sure we really need this here given we will be using whois table for character related lookups anyways, however it does simplify things a bit in some cases since we often lookup by nickname instead of char_id.
• password VARCHAR(64), - Not used by the bot really, but allows web interfaces etc to be done easilly
• password_salt VARCHAR(5), - And allow for password salts
• last_seen INT(11), Last seen online/pgroup
• account_num INT, Raid Point/Alt Account
  
• recieve_announce INT(1) DEFAULT '1', - Recieve !announce
• recieve_invite INT(1) DEFAULT '1', - Recieve !massinv
• auto_invite INT(1), - Auto invite
• added_by VARCHAR(25), - Added to bot by
• added_at INT(11), - Added to bot at
• notify INT(1), - User is on buddylist/logon notice enabled
• user_level INT(1), - User is -1 banned, 0 not a member, 1 guest, 2 member, 3 admin
• admin_level INT(1) DEFAULT '0', - User admin level (old admin table info)
• logon VARCHAR(255), - User logon (old logon table info)
• in_pgroup TINYINIT - is the user in the private group.
  

Numeric Character ID vs nickname vs autonumber ID:
Both the Character ID (provided by FunCom) and a nickname are unique per dimension, thus both values make fine primary keys. In my opinion, the numeric character id is redundant data. I haven't found a need for the numeric ID over the character Nickname, so I'd drop it. An autonumber ID is also not needed, as FunCom and provided us with mutiple options for a primary key already.

Raid Point/Alt Account Number:
Instead of tracking raid points and alts seperatly, how about assigning each user an account number. (A user being defined as a actual person who may have one to invinity characters) When alts are added, the account number is updated to the account number of the main character. So instead of a raid_points table, you would have a user_accounts table which holds attributes common to a group of characters (main+alts)

I've moved last_raid to this table as I think it should be a value common to the user, not the character.

• id int, primary key, auto_increment
• raid_points int
• raiding tinyinit
• main_nickname char
• last_raid INT(11), Last seen joining a raid

To get a listing of alts, you would simply do:
SELECT Nickname FROM MEMBERS WHERE account_num = X;

in_pgroup:
In Omnicom, we've extended our member table to include in_pgroup, which indicates who is in the bot's channel, since we were unable to track online with the buddy list due to the 1,000 character limit. There is probally a better way of doing this, but that's what got hacked in to solve an ongoing problem.

last seen

I was thinking along the lines of:
if guildbot, logging on is last seen time, else last time joined privgroup. Im not sure a non guild bot offhand has any use for knowing the last time someone was online (but not in bot)

Raid bot definitly has use. IE: if the user hasn't joined in X days, remove them from the bot's buddy list. Again, this might be something that should be tied into the raid account, because the member might be active, but they were raiding on an alt. As I stated above, I assoicate last_raid with the user account, not the character.

On Whois:
I'd like it if the whois table names match the keys in the XML. On the version of whois chace I'm running, character names are stored in the name column, not nickname.

The important whois fields are:

firstname - First (RP) name
nickname - Character name (IE: Glarawyn)
lastname - Last (RP) name
rank - org rank.
rank_name - name of org rank.
level - Level (1-220)
profession
gender
breed
defender_rank - Name of Defender Rank (AI Title)
defender_rank_id - Number of Devender Rank (AI Level #)

Due to the different org structures, rank isn't really a useful value to store. rank_name is the more useful value. Since org government type isn't available in the XML data, rank has no context at all and is useless data.

defender_rank seems redundant as well, as it should be a simple manner to translate defender_rank_id (aka AI Level) to defender_rank as it's a 1:1 relationship. ie: a defender rank id of 29 will alwyas be a defender_rank of Vanquisher. A core function could do the translation if needed, but on the other hand there is also value to having it in the whois database.

Hope that's helpful. :)

The issues with CharacterID and Nickname not being truly unique is one of the main reasons i opted to go with a separate ID field (not to mention it makes for easier handling in a web app im working on)

in_pgroup will be part of the upcoming Online table.

account_num. Im a bit worn out atm and not thinking straight. But this would probably make sense to have in the members table.

As for the whois cache, funcom have me torn a bit because they use "name" for the single character and "nickname" in org listings.
As such i tossed a coin on what made the most sense, and imho nickname is a lot clearer than name, not to mention involved altering less code breaking the least possible.

Including the rank_id and defender_rank_id, the information is provided by the XML, and as such it should be present in the whois cache.
Why add a function to the bot to do what is already done for us, it doesn't make sense