You might be able to get it to work, if you are expecting a very small number of visits (say, less than a couple hundred per day) - but it will quickly fall over if the traffic gets much higher and you are hosting Piwik on the Pi itself. The overhead is low during the individual tracking of page views, but is quite significant during the archiving process that generates reports.
First, on every page load, there would be a call by the page to track the page view via piwik.php - this is a very small script which does a MySQL insert for each action. This is unlikely to be a significant drain on the Pi's resources in and of itself. The bigger drain would be from having to load PHP support on your webserver and running a MySQL database on the device; if you're doing those things anyway the overhead would be small.
The second, much heavier load is "archiving", where the reports are actually generated. This can be scheduled as a cron job or triggered when the Piwik admin interface is accessed. If you had a very small number of visits, this ought to run okay - it works fine for lightly accessed sites on low-end shared hosting plans - but at some point you would hit a maximum and your site would just fall over trying to run the archive script. It's not something I'd be comfortable doing in such a constrained environment unless I had a very good understanding that the usage would be very low - and at that point, I'm not sure what the value of including a heavy-duty web analytics solution like Piwik is.
Another solution - and this is probably how I'd do it - is to host Piwik on a different server, and just have the web pages served from the Pi reference it. If the Piwik scripts live on a different server, all the Pi would be doing is including static content that links to those scripts. At that point the impact on the Pi's performance is very near zero.