The value that a trusted certificate authority adds is that they go through (or are supposed to) some effort to verify the identity of the entity that they issue a certificate to. When your email program or web browser gets a proper certificate from the ISP, it can go verify that it was issued by the CA in question and is valid for the site. Or as Wikipedia puts it:
A CA's obligation in such schemes is to verify an applicant's credentials, so that users and relying parties can trust the information in the CA's certificates. CAs use a variety of standards and tests to do so. In essence, the Certificate Authority is responsible for saying "yes, this person is who they say they are, and we, the CA, verify that".
If the user trusts the CA and can verify the CA's signature, then he can also verify that a certain public key does indeed belong to whoever is identified in the certificate.
Now if your ISP conveys to you by some trusted means a new root cert and asks you to import it, and then they always transmit either the root cert or a certificate that chains back to their root, you aren't really losing much over using a trusted third party. The main danger here is that someone breaks into the ISP's cert server and issues themselves some certificates that they can use for an attack.
However if the ISP is making up certificates at random and telling you to just click through any warnings that pop up, you might have a bigger issue. Consider that if someone wants to execute a man in the middle attack, they can make up any random certificate and send it to you in place of the ISP's certificate. You have no good way of telling if it is really from your ISP or from your attacker. In fact, if you are used to getting self-signed root certificates, you will probably just click through any warning that the software might pop up. At this point, the attacker can sniff your encrypted traffic and learn your password or whatever else he is looking for.
You might want to look at the Wikipedia article on intermediate cert authorities.