Quote - Now, if it could be done practically, and efficiently, I'd say the best place to start on the crusade to alienate the warezer's would be to demand serial/registration/proof-of-purchase info for the target application before any purchases from here could be finalized.

Will help nothing, showing a serial number proves nothing, you can show any serial number that downloaded, borrowed or created with a keygen.
Registration is not mandatory, registers only who want to register and most people never register.
It only remains the bill, if someone is able to find where it is and of course it was not thrown in the trash.

Quote - It can access any data that it knows the address of (though unless the program itself is capable of resolving memory references as it loads additional code into its own address space, the address of any data it accesses will need to be known at compile time).

No, the real adress is not known at compile time

Quote -   It can certainly access the stack, through the esp register.

In the stack are only stored local variables and cannot be stored global or static variables.

Quote - Code dynamically loaded by a program during execution is the same as code loaded by the operating system at load time - so long as the pages that the code is loaded to are executable.

The code loaded is not exactly the same needed to be executable

Quote -   Certain architectures (in particular, the x86) for the most part allow code to be executed from anywhere;

Quote - others go to great lengths to insure that no page is allowed to be both writable and executable,

What can be marked as not executable is data, the code to be executed must alway be market as executable and it must be writable too, if not no dynamic allocation of memory would be possible.

Quote - Another possible way to do it would be to have an encrypted DLL that the program decrypts and then links to at runtime

A dll is an exe file, only the extension was changed, the same procedure apllied to exe files is applied to dlls, ocx, acm, drv, ax, and much more. All are exes!

You are not understanting what relocation means, I'll give an example:

CODE SEGMENT
MOV    EAX,[MYDATA]
INC     EAX
IMUL    [SCALE]
balh blah blah
CODE ENDS

DATA SEGMENT
MYDATA DWORD  0
SCALE   DWORD  25
BLAH      WORD  ?
blah blah blah
DATA     ENDS

 This program is accessing from memory MYDATA and SCALE, but as the compiler does not know when the data will be when the program is loaded into the computer memory, it assign values starting from 0 in the data segment and of course the code segment also start from 0.
So the code created by the compiler will be
MOV    EAX,[0000]
INC     EAX
IMUL    [0004]
balh blah blah
But the real adress cannot be 0000, 0004, etc, at this location is stored the interrupt table of the 80xx86.
Also the compiler cannot know where is the data used by other module of the program, each module has his own compilation.
To solve the problem of the unknown memory locations, the compiler create a table of all the memory references and the position in the code where it are.
This table is passed to the linker that will join all the codes created by all the modules and also will create a global table of all the memory references that cannot be resolved by the linker.
The resultant code (it can not be used because has no real memory references) is stored in the exe file, but also is stored the memory reference table in the exe (is stored in the heading of exe before the code itself).
Until now the code is not usable unless you have the miracle when what is in the code and where the memodry is are the same.
When Windows want to execute the program, it loads the code somewhere in the memory and also allocates memory where data will be. Then Windows takes the relocation table, looks at each entry, calculate the exact real memory address and using the other table entry it modifies the code changing the value of the memory referrence to the correct one.

Not only data is relocated, many times code itself is relocated if you use tables.

Want something more dramatic on relocation?
Let see this code in C MessageBox(0,"Hello","",0);
You are calling the function MessageBox, the C compiler will create the code for this line, the code will be pushing the parameters in the stack and then calling the routine MessageBox
PUSH 0
PUSH 0
PUSH [xxxx]  ( the address of the string Hello)
PUSH 0
CALL ???????
What the HELL it will call?, where's the address of MessageBox, where it is located?
MessageBox is a Windows function, this routine doesn't exist in the exe file!!!!
Your compiler, linker and the exe file generated have no way to know where Windows will load in memory the function MessageBox.
What exist in the code in the exe file is CALL 0000 (not exactly this, it use call tables but in the end is resumed in this way).
All Windows functions calls are CALL 0000 in the exe file, no matter which function you use.
When Windows load the code it also will relocate this CALL 0000 and modify the code with CALL 0E83406FA, where 0E83406FA is the real address of MessageBox.
Next time Windows start the address can be 12345678, but your exe file has always 00000000

 

Stupidity also evolves!