The answer is that it's not very different. It has a larger cache and is not explicitly crippled to prevent it working in multiprocessor systems. Xeons also have support for ECC memory, which is not normally supported on consumer CPU chips. Otherwise the basic processor core is much the same.
On older 32 bit systems the Xeon's MMU was slightly more clever in that it could support multiple 4GB process spaces in up to 64GB of physical RAM. SPARC v8 chips had a similar feature in the MMU. This feature worked because of the difference in the number of bits needed to address an offset within a page (12 for a 4KB page) and the number of bits needed to record a page's status (RWX, dirty etc.). The extra bits could be used for a slightly wider physical page reference (24 bits vs. 20 to specify the page number) allowing a 36-bit physical address. However a single process could only see a contiguous 4GB address space at any given time.
Some systems (e.g. Datacentre versions of Windows Server) had an API that allowed a process to control the MMU to overlay chunks of this physical address space into its virtual space. This feature was used in enterprise versions of SQL Server to support larger disk caches.
Most if not all modern CPUs support feature this when running in 32 bit mode, and there are probably plenty of shops still running legacy 32 bit applications in this mode, either on VMs (where the MMU is emulated with a greater or lesser amount of hardware support) or physical tin. However, 64 bit builds are much more prevalent on modern large-memory server builds these days, which allow larger contiguous memory images within a process.