If the installer is depending on CI, you pretty much have to guide the installation process and only allow configuration changes which are going to work. A lot of the work in guiding the process is simply anticipating what a user might do wrong. For example, if you setup a default directory layout which sets the application and system directories outside the web root, you should place an index.php file in the project root and/or the application root which tells the user their site needs to be configured to point to the other location.
In each step of the process, you would most likely display the current configuration, indicate anything which may need to be changed, and only allow the user to take the next step when the installation can continue.
One of the biggest things is tracking what has already been done to prevent the installer from doing anything which might be dangerous on a site which has already been configured to a certain point (or already completed installation). In most cases, you'll probably want layered, even potentially redundant checks in an installer to make sure the installer is permitted to take the requested action.
In some cases, you may want to base whether you can repeat a particular step in the installation on whether a later step in the process was successfully completed. For example, if you allow the user to configure the database connection, you may want to allow them to re-configure the connection at any point until the installation is complete, or until the installer has successfully performed certain operations on the database. You may even want to permit them to configure the database with one account early in the process, then allow them to change the account after the site has finished setting up the database, but before inserting data, then lock out that part of the installer once you verify the data has been successfully inserted. After all, the user might need to use an account with more privileges to create tables, but use an account which can't modify/create/drop tables for daily site operations. If they mis-type something in the configuration, though, the inserts would fail and they'd need to be able to fix the configuration.
Overall, I think it's easier to be able to rely on CI for portions of the installation and it makes sense to work in an environment with which you are already comfortable, rather than having to create your own code or use some different code to manage certain operations. On the other hand, it can be frustrating when you need to more or less duplicate code in your installer because you need to handle an error rather than exit and display an error message. You also have to be very careful about making sure your installer can run to some degree with very few dependencies, making it as flexible as possible in the face of errors.
