The physical address bus' bit width can be more or less then the bit width in a particular memory address, as there is all kinds of hardware hacks you can design into a system to allow weird addressing modes. For example, in some 32-bit systems, the address bus is 52-bits wide. As another example, some CPU instructions can decode a longer address by using a combination of a base address and a lookup table.
At the end of the day, it's the hardware's job to interpret a memory address from a CPU. The CPU just computes the memory address it needs, and sends it to the motherboard's memory controller (remember, we're talking hardware, not software here, see my final note at the bottom). The memory controller's job is to interpret that address, and put the appropriate data on the memory bus.
Since this is all handled on a hardware level, you can actually increase the physical address space of some lower-bit memory systems using a physical address extension. Again, how these extended addresses are handled is part of how the system/hardware was implemented.
Finally, to give some more merit to the hardware hacks I mentioned above, one good example is memory-mapped input/output (MMIO for short). This allows a CPU to access both peripherals and RAM through the address bus itself. Usually this is done though the higher-order memory addresses to avoid lower-order address conflicts. However, this gave rise to the commonly known 3 GB Memory Barrier in all consumer variants of 32-bit Windows operating systems. Again, this is just to show you what is possible on a hardware level.
From a high-level programmer's perspective, this has nothing to do with pointer variables. They always have the same data size, since these address extensions are handled for you by the operating system and/or the hardware itself. Pointer sizes, addresses, and offsets are set/computed by the compiler.