Rodney-
I believe the usual practice (if there is a "usual" practice) is to offer two versions (AJAX and non-AJAX) of a module.  The version installed is based on the user's DNN version since you already know which DNN versions include AJAX.  Unfortunately this means you'll double the sets of code you need to maintain.  A second option would be to go dynamic with a single codeset and have relevant AJAX references added during runtime only when the AJAX library is detected (amounting to self-modifying code -- a very messy option, IMO).

Think Smart....Think S-Mart...
If you decided to go forward with "AJAX" versions of your modules, you might consider creating a "compatability tester" module (without AJAX!) that your consumers can download and install for free to help them determine what Smart-Thinker modules/upgrades are available for their installed version of DNN.  The module would also give guidance on meeting minimum requirements (i.e., what version of DNN to upgrade to) when incompatabilities (no AJAX) are detected.  A simple compatability chart would do much the same but a module simplifies ("dummifies") the process and gives a nice "feel-good" to the consumer that any offered upgrades will work with their copy of DNN.

-mamlin

Rodney, take it a step further in the line of thinking; the AJAX Control toolkit has multiple versions and *could* be used by modules other than your own.  What this means is lets say your module is installed and includes the DLL version "x".  Now they go install a module from another vendor and their module uses version "y" (an older version).  Your module may cease to function because it was reliant on code that exists in version "x" but not in "y". 

I've seen some developers recompile the control toolkit under a completely new assembly name to prevent that sort of conflict but I'm not exactly in love with that idea either because now you effectively have code duplication and that code is loaded multiple times into the AppDomain. 

Back to your original question though... I think you just need to play hardball.  If they want to use your module and you want to support AJAX then they need to upgrade their site or turn on AJAX.  Simple as that.  You may lose sales over it but what you gain is more control over the type of portal configuration you want to support (and you don't have to run two code-trees). 

Another option which echos the suggestion to run two code-trees is to actually code up your project as a single tree but use pre-processor directives to selectively turn on or off the AJAX functionality and you can compile out to two separate PAs.  I think that is just at least a little easier to manage from an upgrade standpoint that two physically separate code-trees but would be a pain to program for since you would effectively have to create two UIs still.

Last option is to still use AJAX but not rely on the control toolkit (in other words, use "pure" ajax methodologies instead of controls and code that relies on UpdatePanels).  I have recently fallen in love with jQuery and use it in conjunction with ASMX or WCF service backends and hook it up with security similar to what Michael Washington suggests in his tutorials about web service security.  More examples about using webservices with jQuery, check out Rick Strahl's blogs (linked to a specific blog post; part 2 of 2; he has another interesting post on November 26 and several more prior to that as well).  This methodology does not require MSAJAX to be installed on the portal in question since it doesn't rely on the MSAJAX framework in any fashion.

Good luck!