BIP32 and BIP39 are describing ways to generate hierarchical deterministic keypairs. In general you generate a deterministic private key first and generate a public key derived from that private key.
Ethereum HD wallets pretty much do the same, here are five hex addresses extracted from the javascript LightWallet (HD):
["8473513ec4b53c6ebe353ab3327c05cc6daad823",
"9e89deeca8ddbe7dfd338e64f9dc2e652a95160f",
"4fb62834520cff47b9e6d60d9b15299a83cd5521",
"2bcf3763459672734b6792f5de250a7cd989fb0a",
"d85785cfef3492f7ba6535de8c08a1676075b094"]
The Ethereum Inter-exchange-Client-Address-Protocol states how valid ICAP addresses are generated. To generate a valid IBAN-compatible address, the first byte of the address has to be 0x00
to reserve the space for the account identifier.
As you can see from the five addresses above, none of them starts with 0. HD accounts therefore are not compatible with direct ICAP addresses which comply with the IBAN standard.
But it is still possible to generate valid ICAP addresses. The specification states, that basic non-IBAN-compatible ICAP addresses don't require an account identifier and can contain 31 alphanumeric characters. Therefore HD accounts are compatible with basic ICAP addresses.