Database design for changing number of fields
KEY-VALUE NO!!!

A table for phone numbers -- sure.  It would have userid, phone_num, and (if you like) a phone type, such as ENUM('fax', 'home', ...).  Then JOIN to the main table.

To keep unlimited, unsearchable data, have a column with a bunch of key-value stuff.  I like to do it in JSON, then compress it (in the app), and store it into a BLOB or MEDIUMBLOB.  That makes it easily accessible by the app, reasonable compact, and quite open-ended.

In the table, have only columns that you need to search on; put the rest into the extra JSON column.

More discussion:
http://forums.mysql.com/read.php?125,428546,428769#msg-428769
http://forums.mysql.com/read.php?125,402095,402218#msg-402218

Another approach is MariaDB's "dynamic columns".  This even lets you index randomly added 'columns'.

2000-3000 customers -- Yawn.