Elliptic Curve Private Keys are only scalar integer values between
n (The Order from
G). These can be encoded in any way, but are usually represented only as 256-bit integers, regardless of which endian the platform uses. When interpreted as an array of bytes, it's simply a 32-byte sequence.
Bitcoin's WIF (Wallet Import Format) uses the 32-byte sequence, prepends a version byte, and then generates a checksum with the Double-SHA256. The first 4 bytes of the checksum are appended to the bytes of the version and the private key to form a sequence of 37 bytes in total. This is then Base58Check-encoded to produce the textual representation of the private keys you trust. The reason they all start with 5 is the version byte.
In the Lightning specifications, there is no specification for the storage or import / export format of private keys, and it is up to the implementers to decide how they should be stored or how they should be exported, if at all. If you prefer, you can use the same WIF format because Lightning uses the same curve as Bitcoin for signing and key exchange.
Private keys are used in Lightning for two different purposes. The Lightning node itself has a single fixed private key that is used both to identify the node (based on its public key) and to sign messages that actually prove to be from that node. It is also used to perform an authenticated key exchange when connecting to peers to prevent MitM attacks.
The other private keys used in Lightning are entries of a Bitcoin wallet that is used to sign transactions related to the channel states, which are standard Bitcoin transaction outputs.
However, it is not enough to know the private key for a particular channel to output for that channel, since it is 2 out of 2 multisig issues and both parties must sign off the transaction to output it. You must therefore be aware of a purchase transaction and a signature of the counterparty for this transaction additionally on your own private key for the channel.
Obviously, it's not very useful to export these private keys alone – you need a more detailed format that includes all the parts needed to keep the current state of the channel to a minimum. In practice, you should also record all previous channel conditions so that you can create a Justice transaction if the other party is trying to propagate an expired channel state, unless you have delegated that role to a Watchtower, who should have a file.