Well, it looks like you are setting yourself up for a real mess, if you are not careful.
Yes, a relational database should be involved, but you need to think carefully about structure in general. Usually, it is not a good idea to duplicate data to different tables, even if you can apply logic constraints to make sure your data stays consistent. Better to find a way to have a central repository of users, and then find a way to make each application query that table. In most relational databases, views provide a good way to accomplish this. A view is simply a query that is saved as if it is another table. Thus, you could have a central table called "users", but a view called "phpBB_users", which contains only the users and columns needed for phpBB. If you name this view the same as phpBB's normal user table, then you don't need to change a line of phpBB code. However, most relational databases still don't allow for INSERTs or UPDATEs into views, only SELECTs. (there are ways around this with triggers, which are another database mechanism, but it will take some thinking)
But, this is just the tip of the iceberg. Without at least some foundation in relational databases, and relational data theory, It would take too long to explain all the possibilities and problems here, but it would require some use of views, triggers, foreign keys, and stored procedures or SQL functions.
The short answer is yes, it can be done, but MySQL won't do it for you anytime soon (maybe eventually it will be capable of all this). So, if your applications depend on MySQL specifically, you will need to code your own workaround. If MySQL is not a requirement, you should look into PostgreSQL as a database, and spend some time reading about exactly what a relational database is. (search for books by Codd, C.J. Date, Fabian Pascal, Hugh Darwen, etc... or any of the books and book reviews at http://techdocs.postgresql.org/)