First, I would recommend checking out Cisco's MPLS FAQ For Beginners, or the NANOG Presentation "MPLS for Dummies" by Richard A Steenbergen. They both have some really good information.
With that said, let me address your questions one at a time. (I have excerpted them in part below.)
1: After the initial convergence of the network, LSPs now exist between all FECs which are typically interfaces on LERs that connect to a subnet.
Yes, LSP's exist towards all reachable FECs. And an MPLS packet could now be switched across the network.
2: Assuming that baseline is correct; How does R1 know it is an LER for an LSP that spans to R6 for example
R1 has no clue that it is part of an LSP that spans to R6. It only cares about the local/connected labels and FECs. That is part of what makes MPLS Label Switching fast and effective. It doesn't have to know the whole path. The router just knows that to reach FEC1, I apply label 1234, and exit interface XYZ.
Then later hops in the path utilize the same process, swapping in the appropriate next hop label and switching the packet on.
As for the bottom line question How are the LERs determined?, a router itself doesn't really know or care if it's an LER. It just knows that when it receives a packet destined for a local destination, with no tag, it delivers it.
In your output above, you can see that the first 4 outgoing FECs have Pop tag listed as the Outgoing Tag. A packet leaving R1 for one of the local subnets on R2 or R3 simply has it's tag popped and forwarded out the appropriate interface.
When R2 or R3 receive that packet, they see no label and process it via the normal routing process which delivers it to a local interface.
To quote the Wikipedia article on MPLS:
At the egress router, when the last label has been popped, only the payload remains. This can be an IP packet, or any of a number of other kinds of payload packet. The egress router must therefore have routing information for the packet's payload, since it must forward it without the help of label lookup tables. An MPLS transit router has no such requirement.
If You don't configure the source address and send the packet to 10.0.1.11, it routed by the default route, and will get the source address from interface attached to the default GW (I suspect 208.46.133.129) automatically, but not 10.5.0.1. Something in the configuration of network (routes, ACLs, IPSec policy, MPLS filters ...) prevents to communication from this address.
Best Answer
Some implementations set the ATT bit automatically and provide you a command or knob under a configuration stanza to disable it. i.e on Juniper: ignore-attached-bit
Others, require you to actually manually configure the ATT bit. i.e Cisco: attached-bit send
So whichever it is, you certainly have power over what you want to achieve, in this case you have decided to perform leaking to have specific routes advertised to your internal area. In this example you have given, leaving the attached bit and thinking about a worst case scenario where there are no failsafe mechanisms, you could end up with a blackhole if you loose connectivity to the specific routes because you still have the default one.
On the other hand, I'm not sure which parameters have been taken into consideration for the leaking, so if it were to be something dynamic where the routes are only leaked if certain conditions you specified are met, then if one of those evaluates to false you will stop seeing those routes and this could potentially result in connectivity loss if there is no other way to work around, hence default route.
In regards to LDP not creating a FEC for the default route introduced by the attached bit in ISIS.
Personally I haven't tested this yet, as soon my hands get on some equipment will do, but for what Google has showed me:
From Microtik:
Reason being: