If the situation is that the names (Fully qualified domain names, like www.example.com) Let’s Encrypt will be signing for are legitimately controlled by your employer, I don’t think this would conflict with the Let’s Encrypt Terms of Service on its own. For example if you control a site https://sounds-like-tech-support.example/ I don’t see a problem with Let’s Encrypt issuing you a certificate for sounds-like-tech-support.example, a name you indeed control.
Obviously if you want to create sites which appear to have names belonging to other people such as google.com or hsbc.co.uk, issuing you with certificates for those names would conflict not only with the Let’s Encrypt ToS, trust store policies and with the Baseline Requirements but even in many places with criminal law. If you want to do that, @leader’s suggestion above is apposite.
If your sites will have FQDNs you legitimately control but the site contents are intended to mislead any visitor into giving away credentials, regardless of whether they received the phishing email - e.g. the site is https://computer-security.example/ but the banner at the top says “Microsoft IT Support” with a Microsoft logo - there is a risk that people who were NOT intentionally targeted by your client are confused by the site and report it as a phishing attack. You should be aware that it is Microsoft policy that CAs wishing to be trusted in their operating system and browsers (which includes Let’s Encrypt and any successful commercial CA) must obey reasonable instructions from Microsoft to revoke certificates issued to these sites. You wouldn’t be able to work around this by choosing a different CA, although @leader’s suggestion would work here too.
To mitigate the above, one possibility is to arrange for the sites NOT to lie to people who are visiting them spontaneously, so that non-target visitors won’t have anything to report. For example you could include a parameter in the links sent out which indicates the client or even the individual email recipient who clicked the link, and if this parameter is not included when a browser accesses the link, just give them a generic message about your company’s service offering. Or you could check the source IP against a list provided by the client, and show the fake login page only to browsers from that list. Employees of a client should be much less likely to make false reports, and their own IT security people can be directed to suppress reports about the test site you’re providing, so that you’re less likely to annoy Microsoft.
Finally, keep in mind that because Let’s Encrypt is fully automated, it will not be possible for them to issue you with certificates for certain “high risk” FQDNs, for example those confusingly like the names of major international banks, or certain famous Internet brands even if you have legitimate control over such a name. At a traditional CA high risk names are supposed to be subject to manual checks (e.g. a human might want to talk to you on the phone about the name you’re requesting) but Let’s Encrypt doesn’t ever do manual checks so it will always refuse high risk issuance outright.