Yes, a LUN will be presented by the HBA to the OS as just another disk;
fdisk -l should list this.
Since the OS has no visibility to the SAN storage, there's no special commands in the OS that will give you any insight into the SAN environment. However, some storage vendors provide tools that will interface with the HBA cards to give you some visibility.
A device's WWN (world-wide name) is an identifier much like an MAC address in IP networking (and is essentially equivalent to the EUI in the iSCSI side of things); it should uniquely identify a member of a storage network (the SAN and the client computers' HBAs both have WWNs) and is used in both transit ("where does this data need to go?") as well as authentication ("which system gets to see this LUN?").
Multipathing is, in essence, a means for eliminating single points of failure, or for balancing load, throughout your storage network.
So, for example, say you have two controller units for your SAN shelves, so that if one goes down the other can still serve the data. Well, that doesn't do you any good if you're only being presented the LUN through a single path - through the now-deceased controller.
Same goes for SAN switches and HBA cards in servers; you don't want to lose connectivity because of the failure of a single piece of equipment. Since each piece of equipment has its own WWN, adding redundancy throughout the system will give you at least 4 paths; each of two HBAs will see each LUN through each of two controllers.
Here's the catch, though - without multipathing awareness, the OS on the client system is going to consider each of those 4 paths as separate disks (going back to the fact that the disks are just presented as-is to the host OS). So, what multipathing gives the OS is the ability to figure out that all those copies of the same disk are, in fact, just multiple paths to get to the same disk, and to either use the alternate paths as failover or to balance load over the paths.