I'm hesitant to write this, because it's going to take time and probably will never even be looked at by WotC. But, I'm an incurable optomist, holding out hope against all odds that WotC really does want a functioning and useful product.
So, here's a design model for making an offline CB that works correctly within the model of a mostly online-only product. This is written from the perspective of Character Builder, but will work with Monster Builder the same way, and probably Compendium, too:
-------
First thing you do is separate the database from the code. The database is the content from all included books and other sources. It resides solely on your servers (except, see below).
Character Builder becomes a software product that resides solely on the customer's computer. It accesses the database online when a live connection exists. It also caches the data to an encrypted local file on the user's computer.
Thus, a character created in CB always knows what stuff it has and the rules tied to those things by accessing the local cache.
From a surface view, this is indistinguishable from the old CB model. It functions exactly like an offline model, EXCEPT ...
Content is unlocked in the online database via whatever mechanism you desire. However, I strongly recommend you graduate this. The current model of "all the data that exists is available to all subscribers all the time" is simply not practical. Instead, each customer must have an inventory of "stuff" that they have previously purchased. This inventory table is kept on the server, but an encrypted copy is kept locally so the customer can't cheat. I'll flesh this out below, but the highlights are needed to understand how all this fits together.
So, in the end, the offline customer sees a cached copy of everything he's entitled to, but no more. While online, you might allow access to unpurchased content as a kind of "teaser" (sort of what you did with the demo version that only went to level 3).
Now, once you have the two pieces in place, you must force the customer to periodically unlock his copy of the local CB. Once a month (or whatever; see below) the client must contact the server and validate itself before access to stored data is allowed again.
Characters created by this tool are stored either locally or on the server/cloud, at the customer's option. Characters can be exported and imported, but only the shell, not the data itself. If a character is loaded onto a system which hasn't paid for some portion of the data it refers to, then you would prompt the customer and ask if they wish to purchase the item. If they do, great. If not, you simply show them the name of the item, but not the data and rules around it.
Let me craft an example which should explain things. Subscriber to DDI gets access to the three core rulebooks, plus AV1 and PHB2. He creates a warlord while connected to the Internet, so that warlord has access to all items available in PHB1, PHB2, and AV1. Plus, any rules that are in DMG1 are incorporated. Notably, he has a couple of items from AV1.
He exports this character to a file (perhaps a dnd4e-2 type file), and gives the file to another person. However, this person doesn't have AV1 (he has the other four books, though). So, this customer cannot use the full character due to missing equipment from AV1. He is prompted with whether he wants to buy that content or not. If not, he can see some kind of moniker that tells him it's unknown information (perhaps the items name is in a different color or something).
Now, the above all works, but there are a few holes. The first one is the encryption for the local database cache. The local DB cache contains all of the info this customer purchased over the years. However, it is only available for a specific amount of time after the last usage connected to the live servers. After that, the client simply can't read the data any more.
Could it be hacked? Not if you use an industrial-strength encryption package to do the job.
Could it be used after the person's subscription expires? Only for the time period allowed. After that, it would no longer function. Alternately, you could allow it to run indefinitely, but only with purchased material. The encryption would still keep the information from getting to other computers.
-----
More:
Using a subscription model as is your intent, customers get access to a certain subset of core material just for being customers. I would think PHB1, MM1, and DMG1, plus maybe essentials belongs in this list. But, the list is short.
For all other reference books, the customer had to have had a live subscription on the month that book was released. (Alternately, they can backfill by buying "months" in which books they desire were released.)
This allows you to offer "deals" in the future. "For two weeks only, if you buy June's subscription we'll include July's as well!" The possibilities are endless.
I would also recommend including a code number (serial number?) inside the printed books. The purchaser of the paper book gets access to the appropriate month in which that book was released. Alternately, you could have two versions of the books available: With DDI unlock code and without it. (You could go one step further and include watermarked PDF files as a third option, but this is a DDI forum. 
)
------
Finally, each customer would have a serial number. This serial number would only be allowed to access cached information from the one serialized client running on one particular system. Any other copy would fail unless the customer is accessing the server live at the time he tries to get at the data.
Customers could in this way purchase "add-on" licenses. These licenses are tied to the parent license. They work with what is essentially the parent's data, but work on another computer. So, one gaming group might have 1 parent licenses and 5 daughter licenses. The daughter licenses would have to have the parent's serial number. Since all of them have to contact the server periodically to allow access to the data, Wizards can at those times verify that there is only one computer in the world using each license.
NOTE: Serializing the computer is not a trivial task, but it can be done. I'm leaving the details out for security reasons, but I'm sure you can figure that part out. If not, you know how to contact me.
A similar concept could be used for DM-level access and player-level access. However, I'm not sure that's needed for a Character Builder application. Still, you might include it. In the model designed above, you can easily make this just another piece of content.
------
In the end, the keys to this whole model are: That each book is tied to a specific date, which is then purchased by the customer. That there are local copies of the data existing on the customer's system, but they have an encryption time-bomb built into them. And finally, each customer's copy is crafted in such a way that it cannot be duplicated elsewhere, using serialization doled out by the server using live contact through an account.