A few years ago I would answer the above question with "because NULL is defined as a void pointer to 0", which is only half correct (and close to being wrong). The answer to this question is much more complicated and thus much more interesting.

Let's start with checking what the C standards (or actually drafts of the standards) say about the (in)famous NULL ptr. The green/yellow/orange colors mark the part that caught my attention. I'll leave the C++0x case for another time (C++0x introduces the nullptr of std::nullptr_t type btw). For TL;DR scroll down, I summarize the points anyway.

C89 aka ANSI C
3.2.2.3 Pointers
[...]
  An integral constant expression with the value 0, or such an
expression cast to type void * , is called a null pointer constant.  If
a null pointer constant is assigned to or compared for equality to a
pointer, the constant is converted to a pointer of that type.  Such a
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.

  Two null pointers, converted through possibly different sequences
of casts to pointer types, shall compare equal.
C1x (draft N1548)
6.3.2.3 Pointers
[...]
3  An integer constant expression with the value 0, or such an expression cast to type
  void *, is called a null pointer constant.66) If a null pointer constant is converted to a
  pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
  to a pointer to any object or function.

4  Conversion of a null pointer to another pointer type yields a null pointer of that type.
  Any two null pointers shall compare equal.

5  An integer may be converted to any pointer type. Except as previously specified, the
  result is implementation-defined, might not be correctly aligned, might not point to an
  entity of the referenced type, and might be a trap representation.67)

66) The macro NULL is defined in (and other headers) as a null pointer constant; see 7.19.
67) The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to
be consistent with the addressing structure of the execution environment.

6.5.3.2 Address and indirection operators
[...]
4 The unary * operator denotes indirection. If the operand points to a function, the result is
a function designator; if it points to an object, the result is an lvalue designating the
object. If the operand has type ‘‘pointer to type’’, the result has type ‘‘type’’. If an
invalid value has been assigned to the pointer, the behavior of the unary * operator is
undefined.102)

102) [...]
Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an
address inappropriately aligned for the type of object pointed to, and the address of an object after the
end of its lifetime.

6.5.9 Equality operators
[...]
6  Two pointers compare equal if and only if both are null pointers, both are pointers to the
  same object (including a pointer to an object and a subobject at its beginning) or function,
  both are pointers to one past the last element of the same array object, or one is a pointer
  to one past the end of one array object and the other is a pointer to the start of a different
  array object that happens to immediately follow the first array object in the address
  space.109)

7.19 Common definitions <stddef.h>
[...]
3  The macros are
    NULL
  which expands to an implementation-defined null pointer constant;

UPDATE: I've corrected some mistakes in the post, since, as Dab pointed out (thanks!), the (int*)0 formula also returns a NULL ptr.

So, to summarize the above (also TL;DR):
1. (The yellow markings) A null pointer is either an integer expression equal to 0 or 0 cast to (void*) type. Important: please note, that it does not say that the null pointer is equal to address 0. It just describes how to get a null pointer constant (cast 0 to void* or just use integer 0 which will be implicit cast during comparison anyway) - treat this as a special case of casting that creates a new magical being called the null pointer.
2. The null pointer constant is defined in stddef.h using the name NULL.
3. If you want a null pointer of other type then void* or integer, you need to cast the null pointer constant to that given type, e.g. (int*)NULL. Important: this explicitly says that you need to use the null pointer constant and not some other value, like e.g. a pointer pointing to address 0.
4. (The orange markings) You can convert an integer into any pointer type (except integer 0 which, as said before, is a special case) and this is consistent with the addressing structure used on a given execution environment. Important: this says that e.g. (int*)0x1234 will point to the address 0x1234, but (int*)0 will not point at address 0, but become a null pointer constant of type int* instead, because it's a null pointer constant (integer 0) cast to type int*. To get a int* pointing at address 0 you would have to do e.g. ((int*)(sizeof(int))) - 1 which, due to pointer arithmetic, would become an int* pointing at address 0.
5. (The green markings) Comparing the null pointer with any legit pointer results in getting a 'false'. I expect this might be rephrased as comparing the null pointer with any non-null pointer will result in getting a 'false'.

The summary: the standard does not say that "NULL is defined as a void pointer to 0", it only says that you get a null ptr constant by using integer 0 or casting 0 to void*, which then gets converted to some totally different being that does not point to address 0.

Going further, we an interesting case:

if( (int*)0 == (((int*)(sizeof(int)) - 1) ) { YES } else { NO }
According to the above points, the answers should be: NO.
That's because the left side is: a null pointer constant (integer 0) cast to type int* - so a null pointer of type int*.
The right side on the other hand is: a pointer of type int* pointing at address 4 (for 32-bit ints) that gets one sizeof(int) worth of bytes subtracted (i.e. 4 bytes in this case) - so it's a pointer to address 0 of type int*.
And, due to the green rule, this should be compare as 'unequal' and result in the 'else' block being executed.

Of course, as one might suspect, executing the code compiled by GCC/MSVC on Windows/Linux-based-OSes resulted in getting a YES. Due to implementation/architectural/historical reasons (at least I suspect so) there is no stored meta-data about a pointer being a null pointer. The implementation just assumes that if a pointer points to address 0 then it's a null pointer (which results to incorrect behavior according to the standard, though is acceptable in practical terms).

OK, some arguments against my way of thinking (aka discussing with myself) and some ways to correct this "issue":

→ "You said that address 0 may contain a legit object, which is not true because you cannot allocate memory at address 0."
Actually this is platform dependent and e.g. both on Windows and Linux you can allocate memory at address 0 - on Windows using the NtAllocateVirtualMemory function and on Linux (afair) using mmap (in both cases with non-zero address that belongs to the first page of the memory). Furthermore, all null-ptr dereference into local priv. escal. exploits abuse this. It's also used (if I remember correctly) by NTVDM. So, you can allocate memory at address zero and you can place some data there, thus you can create a legit pointer that points to address 0.

→ "But ``null'' means ``zero'', so NULL has to point at 0"
It also means "nothing" according to my dictionary ;)

→ "It's hard to store the null pointer as something else on Windows/Linux-based-OS"
Actually I somewhat agree with this one, especially in a 32-bit execution environment.
For example one might say that on Windows in user mode using the value 0x80000000 is better since there is no way to allocate that memory (by default user memory ends at 0x7fffffff).
However, one can allocate this memory if he runs windows with the /3G flag (or similar) and uses the LARGE ADDRESS AWARE flag for the PE - then the process can allocate memory up to 0xC0000000 (exclusive) on a 32-bit system.
→ "So why not use the 0xC0000000 as the null pointer?"
Because when running the same app using WoW64 (Windows on Windows 64) you can use the full 32-bit address space, meaning you can allocate memory at any address. So... no options left.

→ "Hmm, but what about e.g. 0xFFFFFFFF? Reading more then a byte from such address would result in an exception being generated, right?"
Not exactly. I couldn't find the confirmation for this in the Intel Manuals (though I would bet it is somewhere there), but e.g. BOCHS emulator has the following interesting line of code in the file paging.cc:

if (! long64_mode()) laddr2 &= 0xffffffff; /* handle linear address wrap in legacy mode */

So reading e.g. a DWORD from address FFFFFFFF would cause a read from page FFFFF and page 0 (which, as said, can be allocated).
But actually... that's totally not important since:
* You can store a valid char at address FFFFFFFF (so there a legit pointer could have this value)
* The standard explicitly says that dereferencing a null pointer is undefined. It does not have to cause a crash. Furthermore a crash here is not required and should not be taken as a prerequisite for selecting a null pointer value/implementation.

→ "What about 64-bits? Any hope there?"
The case is a little different. For example for Windows 64-bit execution environments on x86, only 44-bits of the 64-bit pointer value are used as an offset into memory (that's OK since the address bus is 48-bit anyway afair). Furthermore, the valid values for the top 20 bits are either all ones or all zeroes.
So, why not use the other 20-bits to contain some invalid value (e.g. 1010 1010 1010 1010 1010 binary) that is guaranteed to be an invalid address by the system architecture? Well.. what about a future case when e.g. on 64-bit systems you will be able to address the whole 64-bit range? It happened with 32-bit /3G on WoW64 after all for the 32-bit range.
But yet, that's one solution.

→ "What about storing a flag ``is a null pointer'' in additional meta-data?"
That's totally doable. The only problem is, that you would have to use 5 bytes to store a 4 byte pointer: 4 byte memory offset + 1 bit padded to a byte for the flag. Oh, wait, actually you would have to pad that to 8 bytes (memory access optimization for array of pointers). So... you would use up 2 times more memory for storing pointers, and thanks to that, the aforementioned comparison of (int*)0 == (void*)0 would return false, as it should! Of course, comparison would be two times slower, since the code would have to check the flags first and the offsets second.
Of course, you could try optimizing the memory usage to e.g. fit all the flags in some array, which would allow not wasting 3 and 7/8 bytes per pointer.
As for dereferengins of such a pointer constructed in such a way, it's important to note you would not have to do checks on dereferencing it since dereferencing a pointer is undefined (i.e. the compiler can assume you never try to do it, and hence not include code that checks if you actually do it). Though it might actually be worth doing for security reasons (it would slow the code down greatly though).

→ "What about agreeing on an address that could never be allocated?"
That's a good solution (and even used on some systems that really disallow allocating the 0 page). Also, I don't think anyone on the current desktop platforms would miss 4KB of memory. It could even be the memory at address 0 to maintain the compatibility with the current apps.
Please note, that reserving the memory is a solution not because dereferencing a pointer that points there would cause an exception, but because it's a way to make sure no object will be stored there. As said before, we don't care what would happen if someone dereferences a NULL pointer (it's undefined)... well OK, we care if we care for security.

→ "But... is this part of the C standard reaaally as important to actually implement any of this?"
Yes. No.
Yes: As mentioned before a common bug in kernel mode code is a NULL pointer dereference and redefining NULL as something non-existing in user-mode memory would save the day. Unfortunately, as mentioned before, it is really hard to choose a right value / right implementation. I would vote for disallowing allocation of the 0th page. But... this isn't exactly a compiler vs standard issue, since the standard says explicitly not to care what happens on dereference.
No: Ignoring the security issue, the uncommon comparison of (int*)0 with NULL giving false is not rationale enough to actually implement any of this imho. It would slow things down greatly, cause compatibility issues, break ABI, etc. But it might be something worth thinking about if we ever design a new platform.

To summarize everything - just don't assume that (void*)0 aka NULL always points to 0 or always does something (e.g. causes an exception) on deference. The first one is implementation specific and the second one is totally undefined.

And that's that.

P.S. One of my pet theories is that playing Magic: The Gathering greatly increases the ability to read through standards & lawyer-style documents (that doesn't mean the above deduction is correct; if you think it's not, please leave a comment ;>).