I'm no expert, but I'll try to answer your questions with my own experience.

1.  The database.     It really doesn't matter WHERE in the database it's stored, because you retrieve it with a ReadOnly Hashtable named Settings.  You can certainly make your own connections and write your required entries, but you'll invariably screw something up or die trying.   

The whole point of a framework is abstraction.  Specifically in this case, data access extraction.  You (the developer) don't have to worry about trivial tasks.   In terms of logic layer and presentation layer code, database entries are trivial.   Trust that a framework member does what it's labeled.   Nothing is perfect, but I can say any problem I've ever had with a module were my own, not a bug in the framework.

2.  It appears that you've already answered this and it's a dead giveaway that the settings are stored in the database.  nvarchar(n) means that you can store n  characters.  In the case of nvarchar (vs. varchar), you can store unicode data, which is necessary for DNN's multilingual support.     (someone chime in if I'm incorrect here.)

3.  Really... 2000 characters should be a lot.  If you had to, you could have to records that pertain to 1 particular setting.  But it's highly unlikely that you'll have to store this many settings.   As far as the multiple modules issue goes, you'll notice that you have to supply an integer moduleID when you store a module - again this is the framework features at work for you.  A module ID make sure that module x's settings do not concur with module y's settings.

My main point.. use the framework.   It will save you lots of headaches.

I hope this helps.   

Daniel